Re: [c-api]Transmutation of an extension object into a read-only buffer adding an integer in-place.
Il giorno venerdì 10 agosto 2012 20:50:08 UTC+2, Stefan Behnel ha scritto: Giacomo Alzetta, 10.08.2012 10:20: I'm trying to implement a c-extension which defines a new class(ModPolynomial on the python side, ModPoly on the C-side). At the moment I'm writing the in-place addition, but I get a *really* strange behaviour. You should take a look at Cython. It makes these things way easier and safer than with manually written C code. It will save you a lot of code, debugging and general hassle. Stefan I already know Cython, but I hope to learn a bit how python works from the C-side writing this extension. Also this work is going to be included in a research work I'm doing, so I'd prefer to stick to Python and C, without having to put cython sources or cython-generated c modules(which I know are almost completely unreadable from a human point of view. Or at least the ones I saw). Anyway thank you for the suggestion. -- http://mail.python.org/mailman/listinfo/python-list
Re: [c-api]Transmutation of an extension object into a read-only buffer adding an integer in-place.
Giacomo Alzetta, 11.08.2012 08:21: I'd prefer to stick to Python and C, without having to put cython sources or cython-generated c modules (which I know are almost completely unreadable from a human point of view. Or at least the ones I saw). And the cool thing is: you don't have to read them. :) Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Unable to execute the script
On 11/08/12 00:48:38, Dennis Lee Bieber wrote: On Fri, 10 Aug 2012 12:35:06 -0700, Smaran Harihar smaran.hari...@gmail.com declaimed the following in gmane.comp.python.general: Hi Tim, this is the output for the ls -lsF filename 8 -rwxr-xr-x 1 root root 5227 Jul 30 13:54 iplantgeo_cgi.py* shudder A CGI script owned by root? Why not? It's not setuid, so being owned by root does not give it any special privileges. What user does your web server run as? I'd recommend setting that user as the owner of the CGI script. That's definitely a bad idea. More so if it's writeable by its owner, as is the case here. It would mean that if a security hole allows intruders to write to arbitrary files, then they can overwrite this script and that would allow them to execute arbitrary code. -- HansM -- http://mail.python.org/mailman/listinfo/python-list
Re: [Newbie] How to wait for asyncronous input
Il 11/08/2012 01:12, Dennis Lee Bieber ha scritto: What you apparently missed is that serial.read() BLOCKs until data is available (unless the port was opened with a read timeout set). [...] serial.read() may, there for, be using select() behind the scenes. Hmm..., so I could open the serial port with timeout=0 so the read(), that runs in a different thread, would block forever, so putting the thread in a sleep state until some bytes arrive. When the main thread wants to close the serial port, the receiving thread can be killed (I don't know why, but I think it will be possible). -- http://mail.python.org/mailman/listinfo/python-list
Re: [c-api]Transmutation of an extension object into a read-only buffer adding an integer in-place.
Il giorno sabato 11 agosto 2012 08:40:18 UTC+2, Stefan Behnel ha scritto: Giacomo Alzetta, 11.08.2012 08:21: I'd prefer to stick to Python and C, without having to put cython sources or cython-generated c modules (which I know are almost completely unreadable from a human point of view. Or at least the ones I saw). And the cool thing is: you don't have to read them. :) Stefan Yes, but since all this code will end-up in the hands of some examiner, he'll have to read them. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: [c-api]Transmutation of an extension object into a read-only buffer adding an integer in-place.
Giacomo Alzetta, 11.08.2012 10:55: Il giorno sabato 11 agosto 2012 08:40:18 UTC+2, Stefan Behnel ha scritto: Giacomo Alzetta, 11.08.2012 08:21: I'd prefer to stick to Python and C, without having to put cython sources or cython-generated c modules (which I know are almost completely unreadable from a human point of view. Or at least the ones I saw). And the cool thing is: you don't have to read them. :) Yes, but since all this code will end-up in the hands of some examiner, he'll have to read them. :) I'd just ask him what he prefers: beautiful Python code with a couple of static type declarations in it, or verbose C code with lots of C-isms and C-API-isms all over the place. If he's smart enough, he'll force you into writing the code in Cython. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: [Newbie] How to wait for asyncronous input
On 11/08/12 09:07:51, pozz wrote: Il 11/08/2012 01:12, Dennis Lee Bieber ha scritto: What you apparently missed is that serial.read() BLOCKs until data is available (unless the port was opened with a read timeout set). [...] serial.read() may, there for, be using select() behind the scenes. Hmm..., so I could open the serial port with timeout=0 so the read(), that runs in a different thread, would block forever, so putting the thread in a sleep state until some bytes arrive. When the main thread wants to close the serial port, the receiving thread can be killed How would you do that? IFAIK, there is no way in Python to kill a thread. The usual work-around is to have a global flag that you'd set to True when the main thread wants to close the port. The read would have a timeout of 1 second of so, so that the reading thread is woken up every second, so it can check that flag and wind up when the flag is set. Hope this helps, -- HansM -- http://mail.python.org/mailman/listinfo/python-list
~~** Unique Floral, Neckline, 4x4 Ornament Embroidery Designs F.R.E.E.!! **~~
Unique Floral Design .. F.R.E.E http://www.embroworld.com/embroidery/4x4-floral-design-132/ Unique Neckline Embroidery Design .. F.R.E.E http://www.theembroidery.com/unique-neckline-embroidery-design-136/ 4x4 Ornament Embroidery Design .. F.R.E.E http://www.embrohome.com/details.php?image_id=74 Enjoy Our New F.R.E.E.B.I.E.S. SUPPORT ME!! Nanees http://www.book-mall.com -- http://mail.python.org/mailman/listinfo/python-list
Xlib: watching key presses without trapping them
Hello there, I'm writing a X Windows program to perform some actions when modifier keys have been released. After looking into the Pykeylogger project (pykeylogger.sourceforge.net), I've gone as far as detecting all events related to modifiers, but then such events get trapped by the program and do not reach other applications. I'm using Python 2.7.3. Thanks for your help. Here it is the program: #! /usr/bin/env python from Xlib.display import Display from Xlib import X Control_R = 64 # Keycode for right Control. Control_L = 108 # Keycode for left Control. # Keycodes we are listening for. I've left out Right Control # to be able to stop the program. keycodes = [Control_L] # Handle X events. def handle_event(event): # Let us know whether this event is about a Key Release of # one of the keys in which we are interested. if event.type == X.KeyRelease: keycode = event.detail if keycode in keycodes: print KeyRelease # Objects needed to call Xlib. display = Display() root = display.screen().root # Tell the X server we want to catch KeyRelease events. root.change_attributes(event_mask = X.KeyReleaseMask) # Grab those keys. for keycode in keycodes: root.grab_key(keycode, X.AnyModifier, 1, X.GrabModeAsync, X.GrabModeAsync) # Event loop. while 1: event = root.display.next_event() handle_event(event) # End of program. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Newbie] How to wait for asyncronous input
On Sat, 11 Aug 2012 11:24:48 +0200, Hans Mulder wrote: On 11/08/12 09:07:51, pozz wrote: When the main thread wants to close the serial port, the receiving thread can be killed How would you do that? IFAIK, there is no way in Python to kill a thread. Correct. The usual work-around is to have a global flag that you'd set to True when the main thread wants to close the port. The read would have a timeout of 1 second of so, so that the reading thread is woken up every second, so it can check that flag and wind up when the flag is set. It doesn't need to be a global flag. You can make the flag an attribute of the thread, and then have the thread check self.flag. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: save dictionary to a file without brackets.
On Fri, 10 Aug 2012 08:53:43 +1000, Chris Angelico wrote: On Fri, Aug 10, 2012 at 8:26 AM, Dave Angel d...@davea.name wrote: On 08/09/2012 06:03 PM, Andrew Cooper wrote: O(n) for all other entries in the dict which suffer a hash collision with the searched entry. True, a sensible choice of hash function will reduce n to 1 in common cases, but it becomes an important consideration for larger datasets. I'm glad you're wrong for CPython's dictionaries. The only time the lookup would degenerate to O[n] would be if the hash table had only one slot. CPython sensibly increases the hash table size when it becomes too small for efficiency. Where have you seen dictionaries so poorly implemented? In vanilla CPython up to version (I think) 3.3, where it's possible to DoS the hash generator. Hash collisions are always possible, just ridiculously unlikely unless deliberately exploited. Not so unlikely actually. py hash(3) 3 py hash(2**64 + 2) 3 py hash(-1) -2 py hash(-2) -2 By its very nature, a hash function cannot fail to have collisions. The problem is that in general you have an essentially unlimited number of objects being mapped to a large but still finite number of hash values. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Xlib: watching key presses without trapping them
On Sat, 11 Aug 2012 10:53:37 +0100, Raffaele Ricciardi wrote: Hello there, I'm writing a X Windows program to perform some actions when modifier keys have been released. After looking into the Pykeylogger project (pykeylogger.sourceforge.net), I've gone as far as detecting all events related to modifiers, but then such events get trapped by the program and do not reach other applications. Questions about specialised modules like Pykeylogger will have a much better chance of being answered if you ask in a dedicated Pykeylogger forum. If there is none, try emailing the author. If you do get an answer elsewhere, please consider passing it on here so others can learn about it too. Have you looked at how GUIs like wxPython and Tkinter handle key events? That might help. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
in-place exponentiation incongruities
I've noticed some incongruities regarding in-place exponentiation. On the C side nb_inplace_power is a ternary function, like nb_power (see here: http://docs.python.org/c-api/typeobj.html?highlight=numbermethods#PyNumberMethods). Obviously you can't pass the third argument using the usual in-place syntax **=. Nevertheless I'd expect to be able to provide the third argument using operator.ipow. But the operator module accept only the two parameter variant. The Number Protocol specify that the ipow operation is the equivalent of the Python statement o1 **= o2 when o3 is Py_None, or an in-place variant of pow(o1, o2, o3) otherwise. Since operator claims to be contain a function port of the operators, I'd expect it to implement ipow with three arguments. I don't see any problem in adding the third argument to it(I mean, sure right now any code that calls ipow(a,b,c) [if exists] is broken, because it will just raise a TypeError, thus adding the argument will not break any code, and would provide more functionality. Also, I don't think there are many objects in the build-ins or standardlib which implement an in-place exponentiation, so this means there wont be much code to change. So my question is: why are there this incongruities? Is there any chance to see this fixed? (in the operator module, or changing the documentation) By the way: I'm asking this because I'm implementing a C-extension and I'd like to implement both pow and ipow. And since it's about polynomials on (Z/nZ)[x]/x^r-1, using the third argument always makes sense. -- http://mail.python.org/mailman/listinfo/python-list
Arithmetic with Boolean values
I have gotten used to switching back and forth between Boolean algebra and numerical values. Python generally makes this quite easy. I just found a case that surprises me. Here is what I want to accomplish: I want to process a list. If the length of the list L is odd, I want to process it once. If len(L) is even, I want to process it twice. I thought I would set up a loop as follows: for x in range(1 + not(len(L) % 2)): # Do stuff This provoked a SyntaxError. I investigated this further with my interpreter (ipython). In [1]: L = range(5) In [2]: L Out[2]: [0, 1, 2, 3, 4] In [3]: len(L) Out[3]: 5 In [4]: len(L) % 2 Out[4]: 1 In [5]: not(1) Out[5]: False In [6]: not(len(L) % 2) Out[6]: False In [7]: 1 + not(len(L) % 2) File ipython console, line 1 1 + not(len(L) % 2) ^ SyntaxError: invalid syntax So as you can see, every thing is working fine until I attempt to add 1 and False. However: In [8]: 0 == False Out[8]: True In [9]: 1 == True Out[9]: True So, 0 and False do pass an equivalency test, as do 1 and True. Furthermore: In [10]: 1 + (len(L) % 2 == 0) Out[10]: 1 Why is using a logical not function, as shown in [7], returning a different result than the test for equivalency as shown in [10]? Of course I'm just going to use [10] in my program, but I'd like to understand the reason that I'm getting that SyntaxError. I've been reading Python style guides, and at least one of them states a preference for using the not syntax over the == 0 syntax. I'm using Python 2.7, in case it matters. -- http://mail.python.org/mailman/listinfo/python-list
Does anyone have an activate script for portable python?
Hi, In Pythons installed with virtualenv there is on windows an activate.bat script, that can be used to setup the cmd-shell such, that the search path for python and pythor elated tools (pip / easy_install) is setup properly. Further there is the deactivate script to set the environment back to it's state before calling activate. Do such a scripts also exist for Portable python? If anybody wrote already such scripts, then couldn't they be added to the official portable python release? I never used portable python so far but can't imagine, that I'm the only one who'd like such a script. -- http://mail.python.org/mailman/listinfo/python-list
Idle no longer works
I can no longer open the Idle IDE for Python on Windows 7. For 3-5 years I used Idle for all my python work. But in January this happens: When I right click on a python file and choose open with Idle nothing happens. If I double-click on the file itself, it briefly opens an MS-DOS looking window, then closes it immediately. I tried installing Eclipse with PyDev. It opens the file, but will not run it in Python. Any idea why? -- http://mail.python.org/mailman/listinfo/python-list
Re: Arithmetic with Boolean values
On Sun, Aug 12, 2012 at 8:30 AM, John Ladasky john_lada...@sbcglobal.net wrote: In [7]: 1 + not(len(L) % 2) File ipython console, line 1 1 + not(len(L) % 2) ^ SyntaxError: invalid syntax This appears to be a limitation of the parser; it's trying to interpret not as a binary operator. 1 + (not(len(L) % 2)) Works just fine with parentheses to enforce the correct interpretation. This also works in Python 3.2, fwiw (except that you need list(range(5)) to create the sample list). ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Arithmetic with Boolean values
On Sat, Aug 11, 2012 at 3:30 PM, John Ladasky john_lada...@sbcglobal.net wrote: snip for x in range(1 + not(len(L) % 2)): # Do stuff This provoked a SyntaxError. I investigated this further with my interpreter (ipython). snip In [5]: not(1) Out[5]: False In [6]: not(len(L) % 2) Out[6]: False In [7]: 1 + not(len(L) % 2) File ipython console, line 1 1 + not(len(L) % 2) ^ SyntaxError: invalid syntax snip Why is using a logical not function, as shown in [7], returning a different result than the test for equivalency as shown in [10]? Note that, in Python, `not` is an unary operator (it's a language keyword in fact), as opposed to a function: Python 2.7.2 (default, Jun 20 2012, 16:23:33) len(abc) 3 # functions are first-class entities in Python, so we can reference them len built-in function len not(1) False # but `not` isn't a function not File stdin, line 1 not ^ SyntaxError: invalid syntax # hence why we don't need to call it not 1 False The parentheses in `not(foo)` are just grouping the `foo` subexpression; they're not indicating a function call. Therefore, in idiomatic Python, such parentheses are omitted whenever possible (which is the majority of the time), and when they are absolutely necessary, a space is included before the opening paren, because we're not making a function call. Thus, you're simply running into an operator precedence issue, which, as Chris A. explained, can be remedied by adding grouping parens around the entire `not` expression; e.g. `(not foo)` Cheers, Chris R. -- http://mail.python.org/mailman/listinfo/python-list
Running Python web apps on shared ASO servers?
Hello I use A Small Orange (ASO) as my web provider. Asking the question in their forum so far didn't work, so I figured I might have a faster answer by asking here. Support replied this in an old thread: Just a CGI option. We don't have enough users to justify adding mod_python support. http://forums.asmallorange.com/topic/4672-python-support/page__hl__python http://forums.asmallorange.com/topic/4918-python-fcgi-verses-mod-python/ Does it mean that ASO only supports writing Python web apps as long-running processes (CGI, FCGI, WSGI, SCGI) instead of embedded Python à la PHP? If that's the case, which smallest tool would you recomment to write basic apps, eg. handling forms, etc.? Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Arithmetic with Boolean values
On 8/11/2012 7:13 PM, Chris Angelico wrote: On Sun, Aug 12, 2012 at 8:30 AM, John Ladasky john_lada...@sbcglobal.net wrote: In [7]: 1 + not(len(L) % 2) File ipython console, line 1 1 + not(len(L) % 2) ^ SyntaxError: invalid syntax This appears to be a limitation of the parser; it's trying to interpret not as a binary operator. I think not. It is lower precedence than all arithmetic operators. The following is worth knowing about and occasionally reviewing. http://docs.python.org/py3k/reference/expressions.html#summary () around % is not needed; not len(L) % 2 works same. So parser sees 1 + not len(L) % 2 with + given higher precedence than not, So it parses as (1 + not) and croaks, as indicated by caret. (We humans see that that is impossible and may boost the precedence in context.) 1 + (not(len(L) % 2)) == 1 + (not len(L) % 2) Works just fine with parentheses to enforce the correct interpretation. This also works in Python 3.2, fwiw (except that you need list(range(5)) to create the sample list). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Arithmetic with Boolean values
On Sun, Aug 12, 2012 at 10:25 AM, Terry Reedy tjre...@udel.edu wrote: On 8/11/2012 7:13 PM, Chris Angelico wrote: This appears to be a limitation of the parser; it's trying to interpret not as a binary operator. I think not. It is lower precedence than all arithmetic operators. (We humans see that that is impossible and may boost the precedence in context.) Ah, I stand corrected. And once again, I kinda expected Python to follow the rules of my mental parser :) Anyway, point stands that parens will fix the issue. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Idle no longer works
On Sat, Aug 11, 2012 at 4:09 PM, Opap-OJ opiney...@yahoo.com wrote: I can no longer open the Idle IDE for Python on Windows 7. For 3-5 years I used Idle for all my python work. But in January this happens: When I right click on a python file and choose open with Idle nothing happens. If I double-click on the file itself, it briefly opens an MS-DOS looking window, then closes it immediately. I tried installing Eclipse with PyDev. It opens the file, but will not run it in Python. Any idea why? -- Have you tried launching Python from the Command Prompt? Open up command prompt and run C:\Python32\python.exe or whatever corresponds to your version of Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Arithmetic with Boolean values
On 11/08/2012 23:30, John Ladasky wrote: I have gotten used to switching back and forth between Boolean algebra and numerical values. Python generally makes this quite easy. I just found a case that surprises me. Here is what I want to accomplish: I want to process a list. If the length of the list L is odd, I want to process it once. If len(L) is even, I want to process it twice. I thought I would set up a loop as follows: for x in range(1 + not(len(L) % 2)): # Do stuff This provoked a SyntaxError. I investigated this further with my interpreter (ipython). In [1]: L = range(5) In [2]: L Out[2]: [0, 1, 2, 3, 4] In [3]: len(L) Out[3]: 5 In [4]: len(L) % 2 Out[4]: 1 In [5]: not(1) Out[5]: False In [6]: not(len(L) % 2) Out[6]: False In [7]: 1 + not(len(L) % 2) File ipython console, line 1 1 + not(len(L) % 2) ^ SyntaxError: invalid syntax So as you can see, every thing is working fine until I attempt to add 1 and False. However: In [8]: 0 == False Out[8]: True In [9]: 1 == True Out[9]: True So, 0 and False do pass an equivalency test, as do 1 and True. Furthermore: In [10]: 1 + (len(L) % 2 == 0) Out[10]: 1 Why is using a logical not function, as shown in [7], returning a different result than the test for equivalency as shown in [10]? Of course I'm just going to use [10] in my program, but I'd like to understand the reason that I'm getting that SyntaxError. I've been reading Python style guides, and at least one of them states a preference for using the not syntax over the == 0 syntax. I'm using Python 2.7, in case it matters. I think the problem is that not isn't a function as such - it doesn't require parentheses, for example. The relevant syntax rules are: a_expr ::= m_expr | a_expr + m_expr | a_expr - m_expr m_expr ::= u_expr | m_expr * u_expr | m_expr // u_expr | m_expr / u_expr | m_expr % u_expr u_expr ::= power | - u_expr | + u_expr | ~ u_expr power ::= primary [** u_expr] primary ::= atom | attributeref | subscription | slicing | call atom ::= identifier | literal | enclosure enclosure ::= parenth_form | list_display | dict_display | set_display | generator_expression | yield_atom call ::= primary ( [argument_list [,] | comprehension] ) In order for your code to work I think we would need to have something like this: primary ::= atom | attributeref | subscription | slicing | call | not_expr not_expr ::= not parenth_form -- http://mail.python.org/mailman/listinfo/python-list
suggesting a launcher wrapper script for portable python
I just started looking at portable Python and was rather surprised, that I didn't find any recommended method in the documentation of how to launch scripts with portable python. Creating py2exe scripts on ones own USB drive seems to be kind of overkill. So here my own thoughts / suggestsions. I'm interestted in feedback of how others use portable pythons and how they run their scripts from a USB stick. Let's assume I install portable python on my USB drive and then I'd like to store self written python scripts on this drive. It would of course be greate if I could just click on the script and they'd be started. However under windows this would not be the case. The python script would either not be started at all or if the PC had his own python installed, then the script would be started with the PC's version of python. Thus a tiny wrapper script would be needed. Suggestion: -- The current directory structore for portable python (2.7) is (assuming that %PP% is the base directory) %PP%/Python-Portable.exe # launches the python interactive shell %PP%/PyScripter-Portable.exe # launches some IDE %PP%/App Let's assume I add two more directories: %PP%/myscripts# location of all callable scripts %PP%/launchers# location with icons one can click on # to start the scripts in myscripts if I wrote a script named %PP%/myscripts/test1.py, and I created an aproprriate named %PP%/launchers/test1.bat then I could just click on test1.bat and the Python script test1.py would be started. If the wrapper script is written properly, then it can look at its own base name and call the related python script. If I dragged and dropped some filenames on the bat file, then they would be passed to sys.argv of the script. Running the script from command line would also work and the present working directory would be preserved (which might be useful in some cases) If the script name would not be .py, but .pyw then it woudl be started with pythonw. T Below suggested script: @echo off REM = REM script to start a python file with portable python REM = REM basepath of this .bat file set basepath=%~dp0 REM create the name of the python file related to this bat file REM Unfortunately I do not know how to normalyze %pyfile%, REM so we got stuck with the '..' set pyfile=%basepath%..\myscripts\%~n0.py If EXIST %pyfile% ( REM a normal console python file with .py suffix %basepath%\..\App\python.exe %pyfile% %* ) ELSE ( If EXIST %pyfile%w ( REM a non console python file with .pyw suffix start %basepath%\..\App\pythonw.exe %pyfile%w %* ) ELSE ( REM found neither a .py nor a .pyw file echo found no python file %pyfile% ) ) REM = REM end of script REM = One minor drawback of my suggested script would be, that a console window pops up for a few seconds when starting a .pyw file. This could be avoided by using either a small compiled C-file (which sounds like overkill though) or by writing a windows scripting host .wsf file. However I don't know this well enough to replicate my batch file. AN article on SO mentions how to write such a script. However it does not parse command line arguments nor does it automatically determine the scripts file name. So any help for creating a .wsf file starting a .pyw file with command line arguments would be appreciated. An alternativce approach could be to provide a scipt named mk_wrapper.bat If one drags and drops a python script on it, then an apropriate wrapper file would be created in the launcher directory. If well done, then this could be implemented such, that the script may be located in an arbitrary location on the same USB drive. I think it would be great if the official portable python release contained some upport for launching scripts. Perhaps it exists alrady and I just didn't find it? If not,then I wouldn't mind if my script or a similiar sand a related README.txt cript were added to the official release -- http://mail.python.org/mailman/listinfo/python-list
Re: Arithmetic with Boolean values
John Ladasky john_lada...@sbcglobal.net writes: I have gotten used to switching back and forth between Boolean algebra and numerical values. Python generally makes this quite easy. Generally ugly though, at least to my tastes. Explicit is better than implicit as the saying goes. If the length of the list L is odd, I want to process it once. If len(L) is even, I want to process it twice for x in range(1 + not(len(L) % 2)): If you really have to do something like that, I'd say for x in range(1 + (len(L) 1)): or for x in range(2 - len(L) % 2): are simpler and avoid those bogus bool conversions. I'd prefer to just say the intention: for x in range(1 if len(L)%2==1 else 2): This provoked a SyntaxError. not is a syntactic keyword and 1 + not is syntactically invalid. You could write 1 + (not ...) as you discovered, but really, it's hackish. -- http://mail.python.org/mailman/listinfo/python-list
Re: Idle no longer works
On 8/11/2012 7:09 PM, Opap-OJ wrote: I can no longer open the Idle IDE for Python on Windows 7. For 3-5 years I used Idle for all my python work. But in January this happens: When I right click on a python file and choose open with Idle nothing happens. If I double-click on the file itself, it briefly opens an MS-DOS looking window, then closes it immediately. That should run the file and discard the output. Above is typical Any idea why? *Something* very specific to your system changed. Either registry associations for .py are screwed, or your Python installation is damaged. Easiest fix is to uninstall and re-install Python. But download a more recent version first. Uninstall might not be needed, but makes process more like to work. In the regular interactive command prompt interpreter import idlelib.idle should start idle. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: in-place exponentiation incongruities
On Sat, 11 Aug 2012 09:54:56 -0700, Giacomo Alzetta wrote: I've noticed some incongruities regarding in-place exponentiation. On the C side nb_inplace_power is a ternary function, like nb_power (see here: http://docs.python.org/c-api/typeobj.html? highlight=numbermethods#PyNumberMethods). Obviously you can't pass the third argument using the usual in-place syntax **=. Nevertheless I'd expect to be able to provide the third argument using operator.ipow. But the operator module accept only the two parameter variant. Why? The operator module implements the ** operator, not the pow() function. If you want the pow() function, you can just use it directly, no need to use operator.pow or operator.ipow. Since ** is a binary operator, it can only accept two arguments. The Number Protocol specify that the ipow operation is the equivalent of the Python statement o1 **= o2 when o3 is Py_None, or an in-place variant of pow(o1, o2, o3) otherwise. Where is that from? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Running Python web apps on shared ASO servers?
Gilles nos...@nospam.com writes: ... Support replied this in an old thread: Just a CGI option. We don't have enough users to justify adding mod_python support. http://forums.asmallorange.com/topic/4672-python-support/page__hl__python http://forums.asmallorange.com/topic/4918-python-fcgi-verses-mod-python/ Does it mean that ASO only supports writing Python web apps as long-running processes (CGI, FCGI, WSGI, SCGI) instead of embedded Python à la PHP? It looks as if you could use CGI to activate Python scripts. There seems to be no mod_python support. You should probably read the mentioned forum resources to learn details about the Python support provided by your web site hoster. -- http://mail.python.org/mailman/listinfo/python-list
[issue15527] Double parens in functions references
Georg Brandl added the comment: Is anyone even reading my messages...? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Georg Brandl added the comment: Deferring. -- priority: release blocker - deferred blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
New submission from Martin v. Löwis: PEP 3118 specifies that the 'c'format denotes UCS-1 characters, yet .tolist() converts the memoryview into a list of bytes objects. This is incorrect; it ought to be a list of string objects (as it should for 'u' and 'w' codes). The same holds for item access. -- messages: 167937 nosy: loewis, skrah priority: normal severity: normal status: open title: memoryview.to_list() incorrect for 'c' format versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Martin v. Löwis added the comment:
To reproduce:
memoryview(array.array('B',b'foo')).cast('c').tolist()
[b'f', b'o', b'o']
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15622
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parens in functions references
Serhiy Storchaka added the comment: Georg, I see that :meth: with arguments works in the form :meth:`name(args) module.class.name`. I believe that the hyperlinks are helpful and it was designed that way. Replacing :meth:/:func:/:c:func: for names with arguments on double backquotes can be done almost automatically. Here's another patch (I like it less). -- Added file: http://bugs.python.org/file26763/doc_dbl_parens_drop_markup.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Stefan Krah added the comment: You have rejected the PEP-3118 'u' and 'w' specifiers here: http://mail.python.org/pipermail/python-dev/2012-March/117390.html Otherwise, memoryview follows the existing struct module syntax: http://docs.python.org/dev/library/struct.html#format-characters I hope it did not escape you that _testbuffer.c *uses* the struct module to verify the correctness of memoryview. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Changes by Stefan Krah stefan-use...@bytereef.org: -- title: memoryview.to_list() incorrect for 'c' format - struct module 'c' specifier does not follow PEP-3118 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15620] readline.clear_history() missing in test_readline.py
Roundup Robot added the comment: New changeset 961a15aff2a6 by Georg Brandl in branch '3.2': Closes #15620: check for presence of readline.clear_history(), which is apparently missing on some readline versions, before calling it in the test. http://hg.python.org/cpython/rev/961a15aff2a6 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15620] readline.clear_history() missing in test_readline.py
Roundup Robot added the comment: New changeset dda08ec9fbd5 by Georg Brandl in branch '2.7': Graft a89d654adaa2 from 3.2 branch. Fixes #15620. http://hg.python.org/cpython/rev/dda08ec9fbd5 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15239] Abandoned Tools/unicode/mkstringprep.py
Changes by Georg Brandl ge...@python.org: -- versions: +Python 3.4 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Martin v. Löwis added the comment: No, I haven't rejected the format codes. What I did ask to revert is that 'u' in the array module denotes Py_UCS4, I requested that it should continue to be compatible with 3.2. I didn't have an opinion on memoryview at all then. It's unfortunate that PEP 3118 deviates from the struct module, however, memoryview is based onthe buffer interface,and its formatcodes ought to conform to the PEP, not to the struct module (IMO). It's easy to see that it *doesn't* follow the struct syntax, as it is possjible to create memoryview objects with other format codes in 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Martin v. Löwis added the comment: That the struct module hasn't been updated to support the PEP 3118 is already reported as issue 3132, please don't confuse the issues. This issue is about memoryview. One solution would be to revert the PEPs decision that 'c' is UCS-1. -- title: struct module 'c' specifier does not follow PEP-3118 - memoryview.to_list() incorrect for 'c' format ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Antoine Pitrou added the comment: I don't know which behaviour is more desirable, but I would consider PEP 3118 a historical document more than a normative spec. Especially when it comes to struct format codes. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: Stefan's proposed definition is correct. Shapes define array types, format strings define entry types, then the actual memory contents define the value. It's not Stefan's definition of equivalence, it's what a statically typed array *means*. The 3.2 way is completely broken, as it considers arrays containing completely different data as equal if the memory layout happens to be the same by coincidence. 3.3 is currently also broken, as it considers arrays that *do* contain the same values to be different. Stefan's patch fixes that by checking the shape and format first, and *then* checking the value. It's exactly the same as doing an instance check in an __eq__ method. The requirement for a canonical format is for sanity's sake: the general equivalence classes are too hard to figure out. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Martin v. Löwis added the comment: Is there anything that still needs to be done on this issue? ISTM that the code is correct as it stands (i.e. Getting a buffer now only uses valid format codes) -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Stefan Krah added the comment: Martin v. L??wis rep...@bugs.python.org wrote: It's unfortunate that PEP 3118 deviates from the struct module, however, memoryview is based onthe buffer interface,and its formatcodes ought to conform to the PEP, not to the struct module (IMO). The struct module itself should conform to PEP-3118, see #3132. I think the struct module should be updated first. The proliferation of subtly different format codes is not manageable. For example, if you use NumPy, there are already differences between NumPy syntax and struct syntax. Also, one should always be able to unpack the tobytes() representation using the struct module and get the same result as from flatten(tolist()). It's easy to see that it *doesn't* follow the struct syntax, as it is possjible to create memoryview objects with other format codes in 3.3. memoryview has *always* allowed arbitrary format strings during construction. In 3.3, it keeps this property for backwards compatibility. It does follow struct syntax whenever it *uses* one of the format codes, like in tolist(). -- title: memoryview.to_list() incorrect for 'c' format - struct module 'c' specifier does not follow PEP-3118 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15239] Abandoned Tools/unicode/mkstringprep.py
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15239 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] memoryview.to_list() incorrect for 'c' format
Stefan Krah added the comment: Martin v. L??wis rep...@bugs.python.org wrote: That the struct module hasn't been updated to support the PEP 3118 is already reported as issue 3132, please don't confuse the issues. This issue is about memoryview. No, it isn't. It was always planned to use struct to do the unpacking for memoryview, see msg71338. On a meta note, I'd appreciate if you were less liberal with words like confusing, especially if you are just beginning to work on an issue that other people have already spent a lot of time on. -- title: struct module 'c' specifier does not follow PEP-3118 - memoryview.to_list() incorrect for 'c' format ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Changes by Stefan Krah stefan-use...@bytereef.org: -- dependencies: +implement PEP 3118 struct changes title: memoryview.to_list() incorrect for 'c' format - struct module 'c' specifier does not follow PEP-3118 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
Antoine Pitrou added the comment:
Victor, your benchmark is buggy (it writes one character at a time). You should
apply the following patch:
$ diff -u bench_stringio_orig.py bench_stringio.py
--- bench_stringio_orig.py 2012-08-11 12:02:16.528321958 +0200
+++ bench_stringio.py 2012-08-11 12:05:53.939536902 +0200
@@ -41,8 +41,8 @@
('bmp', '\u20ac' * k + '\n'),
('non-bmp', '\U0010' * k + '\n'),
):
-bench.bench_func('writer long lines %s' % charset, writer, n // k,
text)
-bench.bench_func('writer-reader long lines %s' % charset,
writer_reader, n // k, text)
+bench.bench_func('writer long lines %s' % charset, writer, n, [text])
+bench.bench_func('writer-reader long lines %s' % charset,
writer_reader, n, [text])
for charset, text in (
('ascii', 'a' * (n // 10) + '\n'),
@@ -50,8 +50,8 @@
('bmp', '\u20ac' * (n // 10) + '\n'),
('non-bmp', '\U0010' * (n // 10) + '\n'),
):
-bench.bench_func('writer very long lines %s' % charset, writer, 10,
text)
-bench.bench_func('writer-reader very long lines %s' % charset,
writer_reader, 10, text)
+bench.bench_func('writer very long lines %s' % charset, writer, 100,
[text])
+bench.bench_func('writer-reader very long lines %s' % charset,
writer_reader, 100, [text])
data = 'abc\n' * n
bench.bench_func('reader ascii', reader, data)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15612
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Martin v. Löwis added the comment: Do you agree or not agree that memoryview.tolist should return a list of str objects for the c code? If you agree, can you please change the title back? If you disagree, please explain why, change the title back, and close the issue as rejected. If you agree, but think that struct should be changed first, create a new issue for the struct change, make that a dependency of this issue, and change the title back. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15528] Better support for finalization with weakrefs
Antoine Pitrou added the comment: In the latest patch, what are broken and priority for? Also, I would question why atexit is false by default. I would find it personally less surprising to be true. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
patrick vrijlandt added the comment: I would not know how to set the MIME-type of a file during upload. This is apparently set by the browser based on the filename (extension). Even (or: especially) if this is a bug in all the current browsers, python should provide the tools to adapt to this situation. I could perhaps request the whole form to be application/octet-stream, but the current multipart/form-data is appropriate for a form. You are right about renaming. The innocent test file test2.txt can be uploaded, but the same file renamed to test2.mht causes an exception. Below is a dump of the posted data (using Chrome in this case); attached a script (requiring bottle.py - www.bottlepy.org or PyPI) that demonstrates the problem. There is no doubt that parsing fails; an exception cannot be the result of successful parsing. The input may be wrong, but python should offer the flexibility to handle wrong input. Instead, are you sure it is appropriate to *automatically* dissect a file? It should be fairly easy to handle for the scripter if he really wants to dig deeper. Headers Origin: http://localhost:10080 Referer: http://localhost:10080/url-get Content-Length: 349 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cache-Control: max-age=0 Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.75 Safari/537.1 Host: localhost:10080 Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4,en-GB;q=0.2 Content-Type: multipart/form-data; boundary=WebKitFormBoundaryBsBVBYDTxou89uBj Body --WebKitFormBoundaryBsBVBYDTxou89uBj Content-Disposition: form-data; name=data; filename=test2.mht Content-Type: multipart/related # dit is een test Dit is een regel Dit is het einde. # --WebKitFormBoundaryBsBVBYDTxou89uBj Content-Disposition: form-data; name=value abc123 --WebKitFormBoundaryBsBVBYDTxou89uBj-- -- Added file: http://bugs.python.org/file26764/cgibug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15444] Incorrectly written contributor's names
Antoine Pitrou added the comment: The patch looks ok to me so, unless someone is opposed to using utf-8 in the doc files, I think it can be committed in 3.x. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Brett Cannon added the comment: So that test case is hard for me to follow since I don't know what a .srctree file is and the file seems to have some magical comments in it. If my assumptions are correct you are generating a C file that does a relative import in the extension module's init function? Has that actually worked in the past? The error you are seeing suggests that the module is not being inserted into sys.modules before executing the body which I have no control over since that's the purview of imp.load_dynamic(). If you skip the relative imports does the import work otherwise? -- resolution: fixed - stage: committed/rejected - test needed status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Brett Cannon added the comment: The reason I ask this is that if I simply move e.g. audioop.so to audioop/__init__.so everything works fine in terms of being able to import that module as a package. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Nick Coghlan added the comment: Whatever the struct module produces for a format code is the same thing that memoryview.to_list() should produce. PEP 3118 contains way too many errors (as has been found out the hard way) to be considered a normative document. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?)
Jordi Puigsegur added the comment: It looks like the change from old to new style classes in python could have triggered this issue. I've created an issue in PyYaml (http://pyyaml.org/ticket/283). Thanks again! -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15616 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15600] expose the finder details used by the FileFinder path hook
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15600 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Stefan Behnel added the comment: Hmm, yes, sounds more like a separate issue than something to add to this ticket. It worked before (starting with Py2.5, which was the first Python version to support relative imports) and only stopped working in 3.3 now. The .srctree test file basically just unfolds into a file system hierarchy with each file named as in the preceding magical comment. The commands in the lines before the first comment line are then executed for the test (usually: build module with distutils, import it, do something with it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Nick Coghlan added the comment: Closing with rationale, as Martin requested The struct module documentation takes precedence over PEP 3118 when it comes to pre-existing format codes, as changing struct is not feasible due to backwards compatibility concerns, and we don't want two conflicting notations for binary format descriptions. PEP 3118 was intended only to define *additional* format characters, which may or may not yet be understood by the struct module. As 'c' is defined by the struct module as returning a bytes object of length one, this is the same interpretation used by memoryview. Thus the current behaviour of both memoryview and struct are considered correct, while it is PEP 3118 that is incorrect in this case: the 'c' entry should not have been in the table, as 'c' was already defined at least as long ago as 1.5.2 (returning an 8-bit string, which then became a bytes object in 3.x). The PEP was also written in a 2.x context (note the mention of 2.5 above the table of new format codes), where the idea of providing a separate code that implicitly performed x.decode(latin-1) to produce a unicode object instead of an 8-bit string object wouldn't necessarily come up. -- dependencies: -implement PEP 3118 struct changes resolution: - invalid stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15444] Incorrectly written contributor's names
Serhiy Storchaka added the comment:
Non-ascii characters already used in a lot (43-50) of doc files.
LC_ALL=C find Doc/ -type f -name '*.rst' -exec egrep --color $(printf
'[\x80-\xFF]+') '{}' +
All touched files already contains non-ascii characters (and Misc/HISTORY
contains invalid UTF-8 sequence).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15444
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3132] implement PEP 3118 struct changes
Nick Coghlan added the comment:
Following up here after rejecting #15622 as invalid
The unicode codes in PEP 3118 need to be seriously rethought before any
related changes are made in the struct module.
1. The 'c' and 's' codes are currently used for raw bytes data (represented as
bytes objects at the Python layer). This means the 'c' code cannot be used as
described in PEP 3118 in a world with strict binary/text separation.
2. Any format codes for UCS1, UCS2 and UCS4 are more usefully modelled on 's'
than they are on 'c' (so that repeat counts create longer strings rather than
lists of strings that each contain a single code point)
3. Given some of the other proposals in PEP 3118, it seems more useful to
define an embedded text format as S{encoding}.
UCS1 would then be S{latin-1}, UCS2 would be approximated as S{utf-16} and
UCS4 would be S{utf-32} and arbitrary encodings would also be supported.
struct packing would implicitly encode from text to bytes while unpacking would
implicitly decode bytes to text. As with 's' a length mismatch in the encoded
form would mean an error.
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15444] Incorrectly written contributor's names
Roundup Robot added the comment: New changeset 3654c711019a by Antoine Pitrou in branch '3.2': Issue #15444: Use proper spelling for non-ASCII contributor names. http://hg.python.org/cpython/rev/3654c711019a New changeset 867de88b69f0 by Antoine Pitrou in branch 'default': Issue #15444: Use proper spelling for non-ASCII contributor names. http://hg.python.org/cpython/rev/867de88b69f0 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15444] Incorrectly written contributor's names
Antoine Pitrou added the comment: Ok, then I've committed the patch. Closing the issue now, thank you. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15444 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15615] More tests for JSON decoder to test Exceptions
Antoine Pitrou added the comment: Hi and thank you. The patch looks fine to me. Could you sign a contributor's agreement: http://www.python.org/psf/contrib/ ? -- nosy: +ezio.melotti, pitrou versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15623] Init time relative imports no longer work from __init__.so modules
New submission from Stefan Behnel: Since CPython 2.5, relative imports could be used from __init__.so package modules. This stopped working in CPython 3.3. This is a follow-up ticket to issue15576. This feature is exercised by Cython's initial_file_path test, which now gives this result: Traceback (most recent call last): File string, line 1, in module File __init__.py, line 8, in init my_test_package (my_test_package/__init__.c:1032) SystemError: Parent module 'my_test_package' not loaded, cannot perform relative import It is meant to check that Cython provides a fake __path__ for the package module for the init function (as long as issue13429 isn't resolved). With that, relative imports worked before. The test code is here, failing in line 21 (each section is a separate file), when it tries to do a relative import at the module level, i.e. at module init time. https://github.com/cython/cython/blob/master/tests/run/initial_file_path.srctree I'm running the test like this: python3 runtests.py --no-cpp --no-pyregr --no-unit --debug -vv initial_file_path I also tried printing sys.modules and the package really isn't registered there yet at the time of the import. -- components: Interpreter Core messages: 167967 nosy: scoder priority: normal severity: normal status: open title: Init time relative imports no longer work from __init__.so modules type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files
Stefan Behnel added the comment: I've created issue15623, so that we can keep this one as fixed. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Nick Coghlan added the comment: However, based on this issue, I have added some comments to #3132 (I think PEP 3118's simplistic approach to embedded text data is broken and a bad idea) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Changes by Nick Coghlan ncogh...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15623] Init time relative imports no longer work from __init__.so modules
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Chris Jerdonek added the comment: Closing with rationale, as Martin requested Status was still open. Was that a tracker bug? -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
Antoine Pitrou added the comment:
I wonder how other systems respond to [...]
if all interfaces except for lo are down
On Mageia Linux 1:
socket.getaddrinfo('localhost', 80, 0, socket.SOCK_STREAM, 0,
socket.AI_ADDRCONFIG)
Traceback (most recent call last):
File stdin, line 1, in module
socket.gaierror: [Errno -5] No address associated with hostname
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15617
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Antoine Pitrou added the comment: No luck there: The tests pass unmodified (100 times with the -F option). You could try -F -j16 or something similar. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Nick Coghlan added the comment: Pretty sure it was just an error on my part. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
STINNER Victor added the comment: Victor, your benchmark is buggy (it writes one character at a time). Oh, it's not what I wanted to test. I attach a new benchmark. Here are the results. PyAccu looks much more appropriate than _PyUnicodeWriter, because it is always faster, except to write 100.000 very long lines. Common platform: CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz CFLAGS: -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Bits: int=32, long=64, long long=64, pointer=64 Python unicode implementation: PEP 393 Platform: Linux-3.4.4-4.fc16.x86_64-x86_64-with-fedora-16-Verne Platform of campaign pyaccu: SCM: hg revision=9804aec74d4a tag=tip branch=default date=2012-08-10 18:55 -0400 Date: 2012-08-11 16:53:46 Python version: 3.3.0b1 (default:9804aec74d4a, Aug 11 2012, 16:53:12) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] Platform of campaign writer: SCM: hg revision=9804aec74d4a+ tag=tip branch=default date=2012-08-10 18:55 -0400 Date: 2012-08-11 16:50:40 Python version: 3.3.0b1 (default:9804aec74d4a+, Aug 11 2012, 16:33:18) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] --+-+--- 10 lines | pyaccu | writer --+-+--- reader short line ascii | 1.53 us (*) |1.46 us writer short line ascii | 4.85 us (*) | 4.48 us (-8%) writer-reader short line ascii| 6.45 us (*) | 5.71 us (-12%) reader short line latin1 | 1.57 us (*) | 1.45 us (-8%) writer short line latin1 | 4.92 us (*) | 4.56 us (-7%) writer-reader short line latin1 | 6.6 us (*) | 5.78 us (-13%) reader short line bmp | 1.64 us (*) | 1.54 us (-6%) writer short line bmp | 5.01 us (*) | 4.43 us (-12%) writer-reader short line bmp | 6.68 us (*) | 5.71 us (-14%) reader short line non-bmp | 1.61 us (*) |1.59 us writer short line non-bmp | 5.1 us (*) | 4.55 us (-11%) writer-reader short line non-bmp | 6.74 us (*) | 5.66 us (-16%) reader long lines ascii | 103 us (*) | 33.4 us (-68%) writer long lines ascii | 998 ns (*) | 836 ns (-16%) writer-reader long lines ascii| 1.45 us (*) | 1.18 us (-19%) reader long lines latin1 | 105 us (*) | 34.2 us (-67%) writer long lines latin1 | 997 ns (*) | 831 ns (-17%) writer-reader long lines latin1 | 1.47 us (*) | 1.2 us (-18%) reader long lines bmp | 121 us (*) | 85.9 us (-29%) writer long lines bmp | 995 ns (*) | 861 ns (-13%) writer-reader long lines bmp | 1.43 us (*) | 1.13 us (-21%) reader long lines non-bmp | 97.1 us (*) |99.7 us writer long lines non-bmp |1 us (*) | 819 ns (-18%) writer-reader long lines non-bmp | 1.4 us (*) | 1.18 us (-16%) reader very long lines ascii | 1.42 us (*) |1.45 us writer very long lines ascii | 3.04 us (*) | 2.88 us (-5%) writer-reader very long lines ascii | 4.59 us (*) | 4.12 us (-10%) reader very long lines latin1 | 1.57 us (*) | 1.47 us (-7%) writer very long lines latin1 | 3.04 us (*) | 2.73 us (-10%) writer-reader very long lines latin1 | 4.66 us (*) | 4.04 us (-13%) reader very long lines bmp| 1.55 us (*) |1.55 us writer very long lines bmp| 3.03 us (*) |2.91 us writer-reader very long lines bmp | 4.72 us (*) | 4.08 us (-14%) reader very long lines non-bmp| 1.55 us (*) |1.49 us writer very long lines non-bmp| 3.09 us (*) | 2.93 us (-5%) writer-reader very long lines non-bmp | 4.59 us (*) | 4.06 us (-12%) --+-+--- Total | 525 us (*) | 342 us (-35%) --+-+--- --+-+--- 1000 lines| pyaccu | writer --+-+--- reader short line ascii | 68.2 us (*) |66.1 us writer short line ascii | 308 us (*) | 307 us writer-reader short line ascii| 378 us (*) | 374 us reader short line latin1 | 72 us (*) |68.5 us writer short line latin1 | 324 us (*) | 313 us writer-reader short line latin1 | 395 us (*) | 383 us reader short line bmp | 74.8 us (*) |71.9 us writer short line bmp | 326 us (*) | 303 us (-7%) writer-reader short line bmp | 397 us (*) | 378 us reader short line non-bmp | 72.9 us (*) |72.6 us writer short line non-bmp | 329 us (*) | 304 us (-8%) writer-reader
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
STINNER Victor added the comment: PyAccu looks much more appropriate than _PyUnicodeWriter, because it is always faster, except to write 100.000 very long lines. Oh... I added colors to my tool, but there was a bug: I used the wrong colors... It's just the opposite. _PyUnicodeWriter is almost always faster, except to write more than 100.000 very long lines. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15561] update subprocess docs to reference io.TextIOWrapper
Andrew Svetlov added the comment: Hmm. As I can see in subprocess.py TextIOWrapper is applied to stdin also in non-buffered (write_through=True) mode. So input will be converted to use '\n' as well. Can you reflect this fact in your patches? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15557] Tests for webbrowser module
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15557 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
Antoine Pitrou added the comment: _PyUnicodeWriter is almost always faster Actually, PyAccu is consistently faster for the writer case, while _PyUnicodeWriter is faster for the writer-reader case. This is not because of PyAccu, but because of the way StringIO uses it: when e.g. readline() is called, the PyAccu result is converted into a PyUCS4* buffer, then each readline() result is converted again by finding the max char in the sub-buffer. So I would suggest using PyAccu, but converting its result to a _PyUnicodeWriter rather than a PyUCS4* buffer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
Serhiy Storchaka added the comment: See benchmark results in issue15381 (the patch is not applicable to StringIO). These numbers show that resize strategy can be much slower append/join strategy on Windows. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15617] FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
Martin v. Löwis added the comment: Antoine: thanks for the report. I fear that this rules out using AI_ADDRCONFIG: IETF has managed to break it. This is really silly. So I'm tempted to close this as won't fix. Comments? Build slaves would be required that a regular lookup of localhost matches the configured loopback addresses (which I feel is a reasonable operational requirement anyway). Floris: another work around is to configure ::1 in your zone. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15622] struct module 'c' specifier does not follow PEP-3118
Martin v. Löwis added the comment: Nick: that's a reasonable view, thanks - in particular the point that PEP 3118 should not be considered normative. I still think that the c code in struct is fairly redundant (with B) as it stands, so I think it should get deprecated and removed - but that's a different issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment:
Nick: I still disagree. Would you agree that array.array constitutes a
statically typed array? Yet
py array.array('b',b'foo') == array.array('B',b'foo')
True
py array.array('i',[1,2,3]) == array.array('L', [1,2,3])
True
So the array object (rightfully) performs comparison on abstract values, not on
memory representation. In Python, a statically typed array still conceptually
contains abstract values, not memory blocks (this is also what Stefan asserts
for NumPy in msg167862). The static typing only restricts the values you can
store in the container, and defines the internal representation on the C level
(plus it typically implies a value storage, instead of a reference storage).
With your and Stefan's proposed semantics, we would get the weird case that for
two array.arrays a and b, it might happen that
a == b and memoryview(a) != memoryview(b)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15573
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment: it might *still* happen, I should say, since this problem is exactly what Victor says this issue intends to solve (for comparison of two 'u' arrays). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15557] Tests for webbrowser module
Chris Jerdonek added the comment: It seems like these tests can be made more DRY. For example, the line `args = popen.cmd_line` appears in every test. You could make an assert_args() helper method to address this. There also seems to be a lot of overlap between tests for each browser. A DRY approach would let one see more easily how the tests differ across browsers. Do you also need to include the test boilerplate at the bottom? See, for example-- http://hg.python.org/cpython/file/867de88b69f0/Lib/test/test_textwrap.py#l732 -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15557 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Stefan Krah added the comment:
So we have two competing proposals:
1) Py_buffers are strongly typed arrays in the ML sense (e.g. array of float,
array of int).
This is probably what I'd prefer on the C level, imagine a function like
function like PyBuffer_Compare(v, w).
Backwards compatibility problem for users who were thinking in terms of
value comparisons:
x = array.array('b', [127])
y = array.array('B', [127])
x == y
True
memoryview(x) == memoryview(y)
False
2) Compare by value, like NumPy arrays do:
x = numpy.array([1, 2, 3], dtype='i')
y = numpy.array([1, 2, 3], dtype='f')
x == y
array([True, True, True], dtype=bool)
I concede that this is probably what users want to see on the Python level.
Backwards compatibility problem for users who were using complicated
structs:
from _testbuffer import *
x = ndarray([(1,1), (2,2), (3,3)], shape=[3], format='hQ')
x == memoryview(x)
False
Reason: While _testbuffer.ndarray already implements tolist() in full
generality, memoryview does not:
x.tolist()
[(1, 1), (2, 2), (3, 3)]
memoryview(x).tolist()
Traceback (most recent call last):
File stdin, line 1, in module
NotImplementedError: memoryview: unsupported format hQ
So while I'm beginning to like Martin's proposal, the implementation is
certainly trickier and will always be quite slow for complicated format
strings.
It would be possible to keep a fast path for the primitive C types
and use the code from _testbuffer.tolist() for the slow cases.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15573
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parens in functions references
Roundup Robot added the comment: New changeset 5e025dc7d728 by Andrew Svetlov in branch 'default': Issue #15527: fix docs, remove double parens by changing markup. http://hg.python.org/cpython/rev/5e025dc7d728 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parens in functions references
Andrew Svetlov added the comment: Applied patch uses ``expr(n)`` as Georg prefer. Serhiy, please close the issue if you have not any upcoming patches. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Martin v. Löwis added the comment: Here is a patch doing the comparison on abstract values if the formats are different. -- Added file: http://bugs.python.org/file26766/abstractcmp.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parens in functions references
Serhiy Storchaka added the comment: Thank you Andrew. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15599] test_circular_imports() of test_threaded_import fails on FreeBSD 9.0
Stefan Krah added the comment:
With -F -j16 I get these failures both on FreeBSD and Linux, but not
the original failure:
==
FAIL: test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests)
--
Traceback (most recent call last):
File /home/stefan/hg/cpython/Lib/test/test_threaded_import.py, line 131, in
test_parallel_meta_path
self.check_parallel_module_init()
File /home/stefan/hg/cpython/Lib/test/test_threaded_import.py, line 120, in
check_parallel_module_init
self.assertFalse(errors)
AssertionError: [AttributeError('module' object has no attribute
'randrange',)] is not false
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15599
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment:
OK, I think I finally understand what Martin is getting at from a semantic
point of view, and I think I can better explain the background of the issue and
why Stefan's proposed solution is both necessary and correct.
The ideal definition of equivalence for memory view objects would actually be:
memoryview(x) == memoryview(y)
if (and only if)
memoryview(x).tolist() == memoryview(y).tolist()
Now, in practice, this approach cannot be implemented, because there are too
many format definitions (whether valid or invalid) that memoryview doesn't
understand (and perhaps will never understand) and because it would be
completely infeasible on large arrays with complex format definitions.
Thus, we are forced to accept a *constraint* on memoryview's definition of
equality: individual values are always compared via raw memory comparison, thus
values stored using different *sizes* or *layouts* in memory will always
compare as unequal, even if they would compare as equal in Python
This is an *acceptable* constraint as, in practice, you don't perform mixed
format arithmetic and it's not a problem if there's no automatic coercion
between sizes and layouts.
The Python 3.2 memoryview effectively uses memcmp() directly treating
everything as a 1D array of bytes data, completely ignoring both shape *and*
format data. Thus:
ab = array('b', [1, 2, 3])
ai = array('i', [1, 2, 3])
aL = array('L', [1, 2, 3])
ab == ai
True
ab == ai == aL
True
memoryview(ab) == memoryview(ai)
False
memoryview(ab) == memoryview(aL)
False
memoryview(ai) == memoryview(aL)
False
This approach leads to some major false positives, such as a floating point
value comparing equal to an integer that happens to share the same binary
representation:
af = array('f', [1.1])
ai = array('i', [1066192077])
af == ai
False
memoryview(af) == memoryview(ai)
True
The changes in 3.3 are aimed primarily at *eliminating those false positives*
by taking into account the shape of the array and the format of the contained
values. It is *not* about changing the fundamental constraint that memoryview
operates at the level of raw memory, rather than Python objects, and thus cares
about memory layout details that are irrelevant after passing through the
Python abstraction layer.
This contrasts with the more limited scope of the array.array module, which
*does* take into account the Python level abstractions. Thus, there will always
be a discrepancy between the two definitions of equality, as memoryview cares
about memory layout details, where array.array does not.
The problem at the moment is that Python 3.3 currently has *spurious* false
negatives that aren't caused by that fundamental constraint that comparisons
must occur based directly on memory contents. Instead, they're being caused by
memoryview returning False for any equality comparison for a format it doesn't
understand. That's unacceptable, and is what Stefan's patch is intended to fix.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15573
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: Short version: 3.3 implemented new constraints on memoryview equality comparisons to eliminate cases that were incorrectly returning True when they should have returned False. However, the format constraints are currently too restrictive, so some memoryview comparisons that correctly returned True in 3.2 are now also returning False. This patch fixes *those* comparisons to once again return True. Moving back to deferred blocked status, since the spurious false negatives are a regression from 3.2. It's fine for beta2 to ship with this problem, but it needs to be fixed for rc1. -- priority: high - deferred blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15561] update subprocess docs to reference io.TextIOWrapper
Chris Jerdonek added the comment: Can you reflect this fact in your patches? Sure. (Though for stdin '\n' is converted to os.linesep and no more.) Would you mind if I also updated the following part of the subprocess documentation to reference the part we are updating, so that the documentation is just in one place? If universal_newlines is True, the file objects stdout and stderr are opened as text files, but lines may be terminated by any of '\n', the Unix end-of-line convention, '\r', the old Macintosh convention or '\r\n', the Windows convention. All of these external representations are seen as '\n' by the Python program. The part we're updating is in the Frequently Used Arguments section and so seems like the natural place for expanded details. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: I can see value in adopting the abstraction approach, but it's not part of this issue. That problem already existed when using memoryview in 3.2, we can wait until 3.4 to fix it. There's an actual, concrete regression in 3.3 that may break code, and comparing with memcmp() when the format strings match is enough to fix it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15573] Support unknown formats in memoryview comparisons
Nick Coghlan added the comment: And, to be honest, I'd be quite happy for congratulations, you have reached the threshold where you need NumPy rather than memoryview to be the long term answer to getting by value comparison semantics. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15624] clarify io.TextIOWrapper newline documentation
New submission from Chris Jerdonek: The documentation of io.TextIOWrapper's newline argument is somewhat confusing and perhaps reversed from what was intended. (For example, the subprocess module uses the reverse terminology.) Either way, it can be improved somewhat. Currently, it says-- * On input, if newline is None,... Lines in the input can end in '\n', '\r', or '\r\n', and these are translated into '\n' before being returned to the caller... * On output, if newline is None, any '\n' characters written are translated to the system default line separator, os.linesep... (from http://docs.python.org/dev/library/io.html#io.TextIOWrapper ) It is somewhat confusing because On input does not mean On input to the buffer, and On output does not mean On output from the buffer. It is the reverse. A minimal change to address this would be something along the lines of-- On input - When reading input from the buffer On output - When writing output to the buffer The same change could also be made to the open() documentation: http://docs.python.org/dev/library/functions.html#open I can prepare a patch for affected versions. -- assignee: docs@python components: Documentation keywords: easy messages: 167995 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: clarify io.TextIOWrapper newline documentation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15624 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15624] clarify io.TextIOWrapper newline documentation
Chris Jerdonek added the comment: Andrew, I'm adding you because this is the documentation that the subprocess module will point to after issue 15561. -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15624 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
