Re: PyWart: Python's import statement and the history of external dependencies
On Fri, Nov 21, 2014 at 6:07 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: On Friday, November 21, 2014 5:59:44 PM UTC-6, Chris Angelico wrote: In other words, what you want is: # today's method, import based on search path import sys # new explicit path method import '/usr/local/lib/python3.5/lib-dynload/math.cpython-35m.so' [...] There are a VERY VERY few cases where you really do want to import a module from a specific file path. For those situations, there are already techniques you can use. Why change the behaviour of import itself? Chris, either take the time to read and understand my posts *FULLY*, or don't bother to reply. I have in no way suggested that we import via filepaths. Stop lying. I see very little substantive difference between what Chris posted and your suggestion of: __search_path__ = ['/usr/local/lib/python3.5/lib-dynload'] import math His comment about non-portability stands. -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
Ian Kelly wrote: On Thu, Nov 20, 2014 at 8:53 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: FOR INSTANCE: Let's say i write a module that presents a reusable GUI calendar widget, and then i name the module calender.py. Then Later, when i try to import *MY* GUI widget named calendar, i will not get *MY* calendar widget, no, i will get the Python calendar module. Because like a fool you created a local module with a totally generic name like calendar and dumped it into the top-level namespace. Firstly, let me say that I am amazed that people have waded through Rick's self-aggrandising purple prose, insults, demands and utter confusion to find something worth engaging him on. Having said that, it's not fair to blame the user for shadowing standard library modules: - All users start off as beginners, who may not be aware that this is even a possibility; - It's hard to keep track of what modules are in the standard library. Which of the following is *not* in Python 3.3's std lib? No cheating by looking them up.) os2emxpath, wave, sndheader, statslib, poplist, plist, pickletools, picklelib, path, cgi, cgitb, copylib, xpath - By default, sys.path is set up so that user modules have priority over std lib modules. Given a name clash, shadowing in inevitable. The Python import system gives you the ability to create packages, so use them -- create a package to contain all the widgets you create. Packages come with their own challenges and complexities, especially if you're trying to support both Python 2 and 3 from the same code base. Besides, for simple uses, packages are overkill. [...] # Contrary to popular belief, sys.path is *NOT* a module, # # no, it's a global! # I really doubt that this is a popular belief. I'm not aware of anyone who believes that sys.path is a module. If they did, a simple import would prove that it is not: py import sys.path Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named path But yes, sys.path is not just global, but process-wide global. *All* modules share the same sys.path. This is another confusing fundamental of Python, it seems *MORE* intuitive that changes to the import search path would only affect the *CURRENT* module's import search path, but that's is not the case! This just seems like it would create a maintenance nightmare. Before you could import anything, you'd have to figure out what the search path is for the particular module you're working and whether it happens to include the particular package you want. You find it doesn't, so you make a local change to the search path. Later, you make the same change to other modules that need to import it. Later still, the package moves to a different location in the file system, and now you get to go through and update every one of those modules with the new directory. Lucky you. That would be horrible. But here's an alternative which is less horrible and maybe even useful. There's still a single process-wide search path, but there's a second per-module search path which is searched first. By default it's empty. So a module can define it's own extra search path: __path__ = ['look/here', 'and/here'] import something without affecting any other modules. And after all that, it would still fail if you happened to want to import both calendar modules into the same module. __path__ = [] import calendar __path__ = ['my/python/modules'] import calendar as mycalendar -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Sat, Nov 22, 2014 at 11:25 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Ian Kelly wrote: - It's hard to keep track of what modules are in the standard library. Which of the following is *not* in Python 3.3's std lib? No cheating by looking them up.) os2emxpath, wave, sndheader, statslib, poplist, plist, pickletools, picklelib, path, cgi, cgitb, copylib, xpath Okay, here's my guesses. os2emxpath: In the stdlib, but more often accessed as os.path while running under OS/2 wave: Not in the stdlib, though I'd avoid the name anyway. sndheader: Not in the stdlib - probably on PyPI though poplist, plist, pickletools, picklelib: I suspect PyPI, not stdlib, but could be wrong path: Not in the stdlib (there's os.path and I doubt there'd be both) cgi, cgitb: In the stdlib copylib: No idea, could be either way. xpath: I'll guess this as not being present. I'm probably pretty wrong, though. # Contrary to popular belief, sys.path is *NOT* a module, # # no, it's a global! # I really doubt that this is a popular belief. I'm not aware of anyone who believes that sys.path is a module. But yes, sys.path is not just global, but process-wide global. *All* modules share the same sys.path. Even leaving aside Rick's sloppy language, I still doubt that it's popular belief that sys.path be module-specific. You're modifying something in a different module, and Python's always maintained that two instances of import sys will give two references to the exact same module object. That would be horrible. But here's an alternative which is less horrible and maybe even useful. There's still a single process-wide search path, but there's a second per-module search path which is searched first. By default it's empty. So a module can define it's own extra search path: __path__ = ['look/here', 'and/here'] import something without affecting any other modules. That's what Rick said first, and then said that if you're going to be explicit, you should do the job properly and not have _any_ implicit paths. Thing is, though, it still breaks the sys.modules concept. Either __path__ is ignored if the module was found in sys.modules, or it's possible to have multiple entries with the same name (which would make it hard to have a module replace itself in sys.modules, currently a supported thing). Although I suppose all it'd require is that sys.modules be keyed by __file__ rather than __name__, so they're identified by fully qualified path and file name. (What does that do in the face of .pyc files?) And after all that, it would still fail if you happened to want to import both calendar modules into the same module. __path__ = [] import calendar __path__ = ['my/python/modules'] import calendar as mycalendar Frankly, if you actually want this, I think it's time to turn to an uglier-but-more-flexible method.like poking around in importlib. (I'm not sure off-hand how you'd go about it, it's not instantly obvious from help(importlib).) I'm more concerned about the possibility of your import succeeding or failing depending on the order of other imports: # foo.py import calendar # bar.py __path__ = ['my/python/modules'] import foo import calendar How's that one to be resolved? That's what I don't like. So long as sys.modules is (a) process-wide and (b) keyed by module name rather than file name, sys.path MUST be process-wide too, and MUST be set on startup, or as soon as possible afterwards. Any module imported prior to altering sys.path will be fetched based on the previous search path - and you have to import sys to change sys.path, which means the minimum set of unalterable modules is, on Python 3.5: rosuav@sikorsky:~$ cat showmods.py import sys print(, .join(sorted(sys.modules.keys( rosuav@sikorsky:~$ python3 showmods.py __main__, _codecs, _collections_abc, _frozen_importlib, _imp, _io, _signal, _sitebuiltins, _stat, _sysconfigdata, _thread, _warnings, _weakref, _weakrefset, abc, builtins, codecs, encodings, encodings.aliases, encodings.latin_1, encodings.utf_8, errno, genericpath, io, marshal, os, os.path, posix, posixpath, site, stat, sys, sysconfig, zipimport ... that's a decent lot of modules you can't fiddle with. Hence PYTHONPATH, which presumably is processed by the interpreter prior to loading any modules. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
Marko Rauhamaa wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: In Python, we have Unicode strings and byte strings. No, you don't. You have strings and bytes: Python has strings of Unicode code points, a.k.a. Unicode strings, or text strings, and strings of bytes, a.k.a. byte strings. These are the plain English descriptive names of the types str and bytes. Textual data in Python is handled with str objects, or strings. Strings are immutable sequences of Unicode code points. String literals are written in a variety of ways: [...] Hence, Unicode string. URL: https://docs.python.org/3/library/stdtypes.html#text-sequence-typ e-str The core built-in types for manipulating binary data are bytes and bytearray. Which are strings of bytes. URL: https://docs.python.org/3/library/stdtypes.html#binary-sequence-t ypes-bytes-bytearray-memoryview Equivalently, I wouldn't mind character strings vs byte strings. Unicode strings are not strings of characters, except informally. Some code points represent non-characters: http://www.unicode.org/faq/private_use.html#nonchar1 They are strings of Unicode code points, but code point string is firstly an inelegant and ugly phrase, and secondly ambiguous. What sort of code points? Baudot codes? ASCII codes? Big5 codes? Tron codes? No, none of the above, they are *Unicode* code points. You haven't given any good reason for objecting to calling Unicode strings by what they are. Maybe you think that it is an implementation detail, and that some version of Python might suddenly and without warning change to only supporting KOI8-R strings or GB2312 strings? If so, you are badly mistaken. The fact that Python strings are Unicode is not an implementation detail, it is part of the language semantics. Unicode strings is not wrong but the technical emphasis on Unicode is as strange as a tire car or rectangular door when car and door are what you usually mean. Tire car makes no sense. Rectangular door makes perfect sense, and in a world where there are dozens of legacy non-rectangular doors, it would be very sensible to specify the kind of door. Just as we specify sliding door, glass door, security door, fire door, flyscreen wire door, and so on. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sun, Nov 23, 2014 at 12:50 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Tire car makes no sense. Rectangular door makes perfect sense, and in a world where there are dozens of legacy non-rectangular doors, it would be very sensible to specify the kind of door. Just as we specify sliding door, glass door, security door, fire door, flyscreen wire door, and so on. Not just legacy - scifi often has non-rectangular doors. (And they're often HORRIBLY impractical. I think the rectangular door is here to stay.) But English is a strange beast. A glass door is made of glass... a flyscreen wire door is made of (at least, has a significant component of) flyscreen, but a fire door isn't made of fire... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: You haven't given any good reason for objecting to calling Unicode strings by what they are. Maybe you think that it is an implementation detail, and that some version of Python might suddenly and without warning change to only supporting KOI8-R strings or GB2312 strings? If so, you are badly mistaken. The fact that Python strings are Unicode is not an implementation detail, it is part of the language semantics. To me, repeating the word Unicode everywhere is giving the (in and of itself impressive) standard too primary a status. While understanding how Unicode, IEEE-754, 2's complement, mark-and-sweep etc work is very useful and occasionally can be taken explicit advantage of, those really are mundane techniques to implement abstractions. Python's strings exist (primarily) so you can express utterances in a human language, aka plain text. They don't exist to express Unicode code points. That would be putting the cart before the horse. Rectangular door makes perfect sense, and in a world where there are dozens of legacy non-rectangular doors, it would be very sensible to specify the kind of door. It makes sense, and yet, I've never heard anyone talk about rectangular doors even though I use numerous doors every day. Why is it, then, that people feel the constant need to add the Unicode epithet to Python's strings, which -- according to its own specification -- are just strings? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
In article 87y4r348uf@elektro.pacujo.net, Marko Rauhamaa ma...@pacujo.net wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: You haven't given any good reason for objecting to calling Unicode strings by what they are. Maybe you think that it is an implementation detail, and that some version of Python might suddenly and without warning change to only supporting KOI8-R strings or GB2312 strings? If so, you are badly mistaken. The fact that Python strings are Unicode is not an implementation detail, it is part of the language semantics. To me, repeating the word Unicode everywhere is giving the (in and of itself impressive) standard too primary a status. While understanding how Unicode, IEEE-754, 2's complement, mark-and-sweep etc work is very useful and occasionally can be taken explicit advantage of, those really are mundane techniques to implement abstractions. Python's strings exist (primarily) so you can express utterances in a human language, aka plain text. They don't exist to express Unicode code points. That would be putting the cart before the horse. Rectangular door makes perfect sense, and in a world where there are dozens of legacy non-rectangular doors, it would be very sensible to specify the kind of door. It makes sense, and yet, I've never heard anyone talk about rectangular doors even though I use numerous doors every day. Why is it, then, that people feel the constant need to add the Unicode epithet to Python's strings, which -- according to its own specification -- are just strings? Marko There's a old joke to the effect that the fields of study which are confident that they're really doing science (i.e. chemistry, biology, physics, astronomy, etc) don't put the word science in their names. It's only the fields of study that are less confident about their status as sciences (computer science, behavioral science, political science, etc) that feel the need to explicitly say science. As if repeating it enough times makes it true. I wonder if something of the same thing applies here? ducking and running Somewhat more seriously, the IEEE-754 point is quite apropos. Back when 754 first came out, there were lots of different floating point implementations. Machines that used 754 touted it in their sales literature and mentioned it all over their documentation. These days, 754 is so ubiquitous, nobody even thinks to mention it, in the same way nobody bothers to mention 2's complement integers. I suspect that some day, the same thing will happen with Unicode. For that matter, we will eventually get to the point where when people say, just plain text, they will mean Unicode, in the same way that just plain text today really means ASCII (and the text/plain MIME type will become a historical curiosity). -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
Roy Smith r...@panix.com: For that matter, we will eventually get to the point where when people say, just plain text, they will mean Unicode, in the same way that just plain text today really means ASCII (and the text/plain MIME type will become a historical curiosity). MIME has: Content-Type: text/plain; charset=UTF-8 (even though UTF-8 isn't a character set but a content encoding). Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Saturday, November 22, 2014 8:14:15 PM UTC+5:30, Roy Smith wrote: Marko Rauhamaa wrote: Steven D'Aprano: You haven't given any good reason for objecting to calling Unicode strings by what they are. Maybe you think that it is an implementation detail, and that some version of Python might suddenly and without warning change to only supporting KOI8-R strings or GB2312 strings? If so, you are badly mistaken. The fact that Python strings are Unicode is not an implementation detail, it is part of the language semantics. To me, repeating the word Unicode everywhere is giving the (in and of itself impressive) standard too primary a status. While understanding how Unicode, IEEE-754, 2's complement, mark-and-sweep etc work is very useful and occasionally can be taken explicit advantage of, those really are mundane techniques to implement abstractions. Python's strings exist (primarily) so you can express utterances in a human language, aka plain text. They don't exist to express Unicode code points. That would be putting the cart before the horse. Rectangular door makes perfect sense, and in a world where there are dozens of legacy non-rectangular doors, it would be very sensible to specify the kind of door. It makes sense, and yet, I've never heard anyone talk about rectangular doors even though I use numerous doors every day. Why is it, then, that people feel the constant need to add the Unicode epithet to Python's strings, which -- according to its own specification -- are just strings? Marko There's a old joke to the effect that the fields of study which are confident that they're really doing science (i.e. chemistry, biology, physics, astronomy, etc) don't put the word science in their names. It's only the fields of study that are less confident about their status as sciences (computer science, behavioral science, political science, etc) that feel the need to explicitly say science. As if repeating it enough times makes it true. I wonder if something of the same thing applies here? ducking and running Somewhat more seriously, the IEEE-754 point is quite apropos. Back when 754 first came out, there were lots of different floating point implementations. Machines that used 754 touted it in their sales literature and mentioned it all over their documentation. These days, 754 is so ubiquitous, nobody even thinks to mention it, in the same way nobody bothers to mention 2's complement integers. I suspect that some day, the same thing will happen with Unicode. For that matter, we will eventually get to the point where when people say, just plain text, they will mean Unicode, in the same way that just plain text today really means ASCII (and the text/plain MIME type will become a historical curiosity). Yes this was my point also -- encodings in general and unicode in particular is a mess (as of 2014). Maybe in a few years the dust will settle. Then saying 'unicode' will become redundant. But until then when we have a rather leaky abstraction having sealing liquid on the hands is preferable to sewage in the house. -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI toolkit(s) status
On 11/22/14, 3:59 AM, wxjmfa...@gmail.com wrote: TeXLive (since 2014, if I'm not wrong) has a GUI installer and package manager, I recognized a tcl/tk/tkinter-like - Perl tool and contrary to Python it works. That's Perl-Tk, which, as I said, is still around, but only runs on Windows and X11/Linux--no native Mac Port. And it hasn't been updated in years, it does not take advantage of recent advances in Tk. -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
wxjmfa...@gmail.com: - By chance, I found on the web a German py dev who was commenting and he had not an updated DUDEN (a German dictionnary). That... leaves me utterly speachless! Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On 22/11/2014 17:49, Marko Rauhamaa wrote: wxjmfa...@gmail.com: - By chance, I found on the web a German py dev who was commenting and he had not an updated DUDEN (a German dictionnary). That... leaves me utterly speachless! Marko Please don't feed him. Your average troll is bad enough but he really takes the biscuit. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI toolkit(s) status
Am 22.11.14 19:33, schrieb wxjmfa...@gmail.com: As you are rewriting unicode, a small suggestion/request. Assume that one processes a part of the Bible in polytonic Greek, one has to create a ton of temporary (locale) letters, °)))o αὐτὸν τὸν ἰχθύα ὁ Χριστιανὸς ἔγραψε τρόλλοι -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On 11/21/2014 08:43 PM, Steven D'Aprano wrote: random...@fastmail.us wrote: I think I tried on at least one python version and printing the tuple crashed with a recursion depth error, since it had no special protection for this case the way list printing does. It works fine now (Python 3.3). py L = [] py t = (L, None) py L.append(L) py L.append(t) # For good measure. py print(t) ([[...], (...)], None) This is a tuple in a list in a tuple, not a tuple in a tuple. -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sun, Nov 23, 2014 at 5:17 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: Please don't feed him. Your average troll is bad enough but he really takes the biscuit. ... someone was feeding him biscuits? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On 2014-11-22 23:25, Steven D'Aprano wrote: Having said that, it's not fair to blame the user for shadowing standard library modules: - All users start off as beginners, who may not be aware that this is even a possibility; While it's one thing to explicitly shadow a module (creating your own module named calendar; if you need the stdlib module, you know it and have to rename your local one), the implicit shadowing has stung me a number of times. I'll unthinkingly create an email.py and then need to send email so I'll import smtplib (which internally imports stdlib's email.py but it finds my local email.py) and everything falls over. The error messages don't make it obvious what happened. I've been burned enough times that I now know not to do this. But it was certainly burned into my mind after the 3rd time it happened. And after all that, it would still fail if you happened to want to import both calendar modules into the same module. __path__ = [] import calendar __path__ = ['my/python/modules'] import calendar as mycalendar Hrm. Never knew this. Could you point me at some docs on that? (searching for __path__ on python.org isn't turning up much that jumps out at me as being correlated) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On 11/21/2014 2:30 PM, Zachary Ware wrote: On Fri, Nov 21, 2014 at 12:37 PM, Ian Kelly ian.g.ke...@gmail.com wrote: Here's a nice crash. I thought this might similarly produce a recursion depth error, but no, it's a seg fault! $ cat test.py import itertools l = [] it = itertools.chain.from_iterable(l) l.append(it) next(it) $ python3 test.py Segmentation fault (core dumped) Would you mind submitting a bug report for that? Any segfault produced by pure Python code must be fixed. This is too important to lose. http://bugs.python.org/issue22920 -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On 22/11/2014 20:17, Chris Angelico wrote: On Sun, Nov 23, 2014 at 5:17 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: Please don't feed him. Your average troll is bad enough but he really takes the biscuit. ... someone was feeding him biscuits? ChrisA Surely it's better than feeding him unicode? As I needed cheering up I ventured over to gg and wasn't disappointed reading his latest rubbish. My favourite find thousand and one ways to make Python crashing or failing. but I don't recall a single bug report in the last two years from anybody regarding problems with the FSR, or have I missed something? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sun, Nov 23, 2014 at 9:04 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: My favourite find thousand and one ways to make Python crashing or failing. but I don't recall a single bug report in the last two years from anybody regarding problems with the FSR, or have I missed something? What you've missed is the grammar of the sentence you've (partially) quoted. Clearly he is seeking to make Python, and he is crashing or failing. My advice to him: Stop trying to build complex software while in command of a car. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On 22/11/2014 22:31, Chris Angelico wrote: On Sun, Nov 23, 2014 at 9:04 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: My favourite find thousand and one ways to make Python crashing or failing. but I don't recall a single bug report in the last two years from anybody regarding problems with the FSR, or have I missed something? What you've missed is the grammar of the sentence you've (partially) quoted. Clearly he is seeking to make Python, and he is crashing or failing. My advice to him: Stop trying to build complex software while in command of a car. ChrisA What? The entire message follows. quote I think you are not understanding the point very well. Py32 and Qt derivative + plenty of dirty tricks. (It will probably not be rendered correctly.) Write something like this (an interactive interpreter) in Py32 and Py33 and see what happens: print(999) 999 sys.version '3.2.5 (default, May 15 2013, 23:06:03) [MSC v.1500 32 bit (Intel)]' # note the emoji and the private use area (plane 15) a = 'abc\u00e9\u0153\u20ac\u1e9e\U0001f300\udb80\udc00z' print(a) abc需ẞ z Note: it can be cut/copied/pasted with a MS product. jmf PS I have to recognized, I'm slowly getting tired to find thousand and one ways to make Python crashing or failing. /quote That is a standard Windows build. He is again conflating problems with using the Windows command line for a given code page with the FSR. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
Tim Chase wrote: On 2014-11-22 23:25, Steven D'Aprano wrote: And after all that, it would still fail if you happened to want to import both calendar modules into the same module. __path__ = [] import calendar __path__ = ['my/python/modules'] import calendar as mycalendar Hrm. Never knew this. Could you point me at some docs on that? (searching for __path__ on python.org isn't turning up much that jumps out at me as being correlated) You've misunderstood what I said, I was proposing it as a hypothetical feature, not something existing. Sorry for any confusion. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Fri, Nov 21, 2014, at 23:38, Steven D'Aprano wrote: I really don't understand what bothers you about this. In Python, we have Unicode strings and byte strings. In computing in general, strings can consist of Unicode characters, ASCII characters, Tron characters, EBCDID characters, ISO-8859-7 characters, and literally dozens of others. It boogles my mind that you are so opposed to being explicit about what sort of string we are dealing with. I think he means that it should be implementation-defined with an API that does not allow programs to make assumptions about the encoding, like C. To allow for implementations that use a different character set. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sat, Nov 22, 2014, at 18:38, Mark Lawrence wrote: ... That is a standard Windows build. He is again conflating problems with using the Windows command line for a given code page with the FSR. The thing is, with a truetype font selected, a correctly written win32 console problem should be able to print any character without caring about codepages (via use of WriteConsoleW instead of WriteFile). You cannot rely on having the codepage set to 65001, especially since 65001 isn't actually a fully supported codepage. In my opinion it is a deficiency in the win32 support, rather than unicode support (and certainly nothing to do with the FSR), but it _is_ a deficiency. -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On 2014-11-23 12:00, Steven D'Aprano wrote: And after all that, it would still fail if you happened to want to import both calendar modules into the same module. __path__ = [] import calendar __path__ = ['my/python/modules'] import calendar as mycalendar Hrm. Never knew this. Could you point me at some docs on that? (searching for __path__ on python.org isn't turning up much that jumps out at me as being correlated) You've misunderstood what I said, I was proposing it as a hypothetical feature, not something existing. Sorry for any confusion. Ah, thanks. I wondered but should have tried it out to see that it wasn't an existing feature. I'm not sure if/when I would use such a feature, but it was at least an interesting idea. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sun, Nov 23, 2014 at 12:52 PM, random...@fastmail.us wrote: On Sat, Nov 22, 2014, at 18:38, Mark Lawrence wrote: ... That is a standard Windows build. He is again conflating problems with using the Windows command line for a given code page with the FSR. The thing is, with a truetype font selected, a correctly written win32 console problem should be able to print any character without caring about codepages (via use of WriteConsoleW instead of WriteFile). You cannot rely on having the codepage set to 65001, especially since 65001 isn't actually a fully supported codepage. Is that true? Does WriteConsoleW support every Unicode character? It's not obvious from the docs whether it uses UCS-2 or UTF-16 (or maybe something else). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
SQLite3 in Python 2.7 Rejecting Foreign Key Insert
I've built a database in SQLite3 to be embedded into a python application using wxPython 2.8.12 and Python 2.7.6. I'm using Sqliteman to manage the database directly and make changes to the structure when necessary. One item that's been bugging me is when I'm inserting records into one particular table: The parent table is called borehole, and the 'borehole_id' field is TEXT. It's essentially a name field, because every borehole name is naturally unique, therefore I thought an autoincrementing integer would be superfluous. A related field is called core_run, and its foreign key field is named of_borehole -- of course its type is TEXT NOT NULL as well. It's described in the DESCRIBE TABLE feature of Sqliteman as FOREIGN KEY(of_borehole) REFERENCES borehole(borehole_id) When I use Sqliteman to manually create a record using INSERT INTO core_run VALUES..., it works properly. However, when I do the same thing, using the same test data, from inside Python, I get the following SQLite error 'foreign key mismatch - core_run referencing borehole' To make sure the core_run.of_borehole and borehole.borehole_id fields are equivalent, I inserted a logging statement just prior to the database cursor. [code] # retrieve the borehole id field, check it matches with of_borehole field db_cursor.execute(select borehole_id from borehole where borehole_id = ?, (runfields[1],)) relatedbh = db_cursor.fetchone()[0] logging.info(Related borehole_id is %s, of_borehole is %s, relatedbh, runfields[1]) [/code] runfields[1] here is the of_borehole field taken from the applications GUI field. In this case, the displayed data from both is identical -- the logging line comes back as: INFO:Related borehole_id is testbh3, of_borehole is testbh3 So the data type is the same, and the content appears to be the same. So why would there be a foreign key mismatch? Is it possible that there is some invisible code in the string which isn't being detected by the logging command? Is this just a quirk of the Sqlite3 implementation in Python that demands foreign keys be integers? I feel like I've hit a brick wall here. Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: How to access Qt components loaded from file?
On Friday, November 21, 2014 2:49:45 AM UTC+5:30, Juan Christian wrote: On Thu Nov 20 2014 at 7:07:10 PM Mark Lawrence wrote: You also need to study the difference between top posting, interspersed posting and bottom posting. The second and third are very much the prefered styles here. Yes I know, but I'm using the new Google Inbox, and I limited to what I can do when replying, to do the right way I have to do many steps now... In gmail 'compose-box' there is a small downward triangle at the right bottom of screen. That allows you to choose plain text mode. -- https://mail.python.org/mailman/listinfo/python-list
Re: SQLite3 in Python 2.7 Rejecting Foreign Key Insert
On Sun, Nov 23, 2014 at 1:11 PM, llanitedave llanited...@birdandflower.com wrote: logging.info(Related borehole_id is %s, of_borehole is %s, relatedbh, runfields[1]) In this case, the displayed data from both is identical -- the logging line comes back as: INFO:Related borehole_id is testbh3, of_borehole is testbh3 So the data type is the same, and the content appears to be the same. So why would there be a foreign key mismatch? Is it possible that there is some invisible code in the string which isn't being detected by the logging command? Is this just a quirk of the Sqlite3 implementation in Python that demands foreign keys be integers? First thing I'd do, if I'm suspicious of invisible stuff in a string, is to change those %s markers to %r. You'll get a quoted string (so you can see if there's leading/trailing whitespace), any non-ASCII characters will be escaped (assuming this is a byte string in Python 2, which seems to be the case), and control characters like newlines will become escapes too. But I've seen a number of very strange and annoying behaviours out of SQLite as regards foreign keys. It seems that sometimes integrity checks just aren't being done, and I don't know why. Can you switch to a PostgreSQL back-end to see if the problem (a) suddenly disappears, (b) suddenly appears at a completely different point, or (c) now has a more informative error message? Chances are all you need to do is change your import and connection setup, and all the rest will work just the same. By the way, naming convention: I prefer to use id only when it's actually a numeric ID. For something like this, I'd call it name, since that's what it is. But that won't be affecting your foreign key. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
I have no class
What do I need to do to make a and b have different values? import random class RPS: throw=random.randrange(3) a=RPS b=RPS print (a ,a.throw) print (b ,b.throw) if a.throw == b.throw: print(Tie) elif (a.throw - b.throw)%3==1: print(a Wins) else: print(b Wins) - I tried: class RPS: def __init__(self): self.throw=random.randrange(3) AttributeError: type object 'RPS' has no attribute 'throw' -- https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sat, Nov 22, 2014, at 21:47, Seymore4Head wrote: What do I need to do to make a and b have different values? import random class RPS: throw=random.randrange(3) a=RPS b=RPS print (a ,a.throw) print (b ,b.throw) if a.throw == b.throw: print(Tie) elif (a.throw - b.throw)%3==1: print(a Wins) else: print(b Wins) - I tried: class RPS: def __init__(self): self.throw=random.randrange(3) AttributeError: type object 'RPS' has no attribute 'throw' You need that class, and also a=RPS(); b=RPS(). -- https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sunday, November 23, 2014 8:17:24 AM UTC+5:30, Seymore4Head wrote: What do I need to do to make a and b have different values? import random class RPS: throw=random.randrange(3) a=RPS b=RPS print (a ,a.throw) print (b ,b.throw) if a.throw == b.throw: print(Tie) elif (a.throw - b.throw)%3==1: print(a Wins) else: print(b Wins) - I tried: class RPS: def __init__(self): self.throw=random.randrange(3) AttributeError: type object 'RPS' has no attribute 'throw' Works as far as I can see: import random class RPS: def __init__(self): self.throw=random.randrange(3) - a = RPS() a.throw 0 a = RPS() a.throw 2 a = RPS() a.throw 2 -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sat, Nov 22, 2014, at 21:11, Chris Angelico wrote: Is that true? Does WriteConsoleW support every Unicode character? It's not obvious from the docs whether it uses UCS-2 or UTF-16 (or maybe something else). I was defining every unicode character loosely. There are certainly display problems (there are display problems with wide characters on non-CJK windows versions, too), but if you write a surrogate pair, you'll get something that can copy to the clipboard as a surrogate pair, and get the same thing that writing a non-BMP UTF-8 character with codepage 65001 will give you. And you certainly won't get an error. -- https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On 11/22/14 9:47 PM, Seymore4Head wrote: What do I need to do to make a and b have different values? import random class RPS: throw=random.randrange(3) a=RPS b=RPS This simply makes a and b into other names for the class RPS. To instantiate a class to make an object, you have to call it: a = RPS() b = RPS() - I tried: class RPS: def __init__(self): self.throw=random.randrange(3) AttributeError: type object 'RPS' has no attribute 'throw' This is the right way to define the class (almost: in Py 2, you should derive from object). Once you make an object from it, you will have what you want: class RPS(object): def __init__(self): self.throw = random.randrange(3) a = RPS() b = RPS() print a.throw print b.throw -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sat, 22 Nov 2014 22:08:31 -0500, random...@fastmail.us wrote: On Sat, Nov 22, 2014, at 21:47, Seymore4Head wrote: What do I need to do to make a and b have different values? import random class RPS: throw=random.randrange(3) a=RPS b=RPS print (a ,a.throw) print (b ,b.throw) if a.throw == b.throw: print(Tie) elif (a.throw - b.throw)%3==1: print(a Wins) else: print(b Wins) - I tried: class RPS: def __init__(self): self.throw=random.randrange(3) AttributeError: type object 'RPS' has no attribute 'throw' You need that class, and also a=RPS(); b=RPS(). That works. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sat, 22 Nov 2014 19:09:27 -0800 (PST), Rustom Mody rustompm...@gmail.com wrote: On Sunday, November 23, 2014 8:17:24 AM UTC+5:30, Seymore4Head wrote: What do I need to do to make a and b have different values? import random class RPS: throw=random.randrange(3) a=RPS b=RPS print (a ,a.throw) print (b ,b.throw) if a.throw == b.throw: print(Tie) elif (a.throw - b.throw)%3==1: print(a Wins) else: print(b Wins) - I tried: class RPS: def __init__(self): self.throw=random.randrange(3) AttributeError: type object 'RPS' has no attribute 'throw' Works as far as I can see: import random class RPS: def __init__(self): self.throw=random.randrange(3) - a = RPS() a.throw 0 a = RPS() a.throw 2 a = RPS() a.throw 2 It works when you remember to include the () I am still making rookie mistakes. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sat, 22 Nov 2014 22:14:21 -0500, Ned Batchelder
n...@nedbatchelder.com wrote:
On 11/22/14 9:47 PM, Seymore4Head wrote:
What do I need to do to make a and b have different values?
import random
class RPS:
throw=random.randrange(3)
a=RPS
b=RPS
This simply makes a and b into other names for the class RPS. To
instantiate a class to make an object, you have to call it:
a = RPS()
b = RPS()
-
I tried:
class RPS:
def __init__(self):
self.throw=random.randrange(3)
AttributeError: type object 'RPS' has no attribute 'throw'
This is the right way to define the class (almost: in Py 2, you should
derive from object). Once you make an object from it, you will have what
you want:
class RPS(object):
def __init__(self):
self.throw = random.randrange(3)
a = RPS()
b = RPS()
print a.throw
print b.throw
Now I am trying to add a dictionary, but it is broke too.
How do I fix:
class RPS:
key={0:rock, 1:paper,2:scissors};
def __init__(self):
self.throw=random.randrange(3)
self.key=key[self.throw]
--
https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sat, Nov 22, 2014 at 10:35 PM, Seymore4Head
Seymore4Head@hotmail.invalid wrote:
On Sat, 22 Nov 2014 22:14:21 -0500, Ned Batchelder
n...@nedbatchelder.com wrote:
On 11/22/14 9:47 PM, Seymore4Head wrote:
What do I need to do to make a and b have different values?
import random
class RPS:
throw=random.randrange(3)
a=RPS
b=RPS
This simply makes a and b into other names for the class RPS. To
instantiate a class to make an object, you have to call it:
a = RPS()
b = RPS()
-
I tried:
class RPS:
def __init__(self):
self.throw=random.randrange(3)
AttributeError: type object 'RPS' has no attribute 'throw'
This is the right way to define the class (almost: in Py 2, you should
derive from object). Once you make an object from it, you will have what
you want:
class RPS(object):
def __init__(self):
self.throw = random.randrange(3)
a = RPS()
b = RPS()
print a.throw
print b.throw
Now I am trying to add a dictionary, but it is broke too.
How do I fix:
class RPS:
key={0:rock, 1:paper,2:scissors};
def __init__(self):
self.throw=random.randrange(3)
self.key=key[self.throw]
--
https://mail.python.org/mailman/listinfo/python-list
can you please show traceback and output?
--
Joel Goldstick
http://joelgoldstick.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: SQLite3 in Python 2.7 Rejecting Foreign Key Insert
On Saturday, November 22, 2014 6:22:32 PM UTC-8, Chris Angelico wrote: On Sun, Nov 23, 2014 at 1:11 PM, llanitedave wrote: logging.info(Related borehole_id is %s, of_borehole is %s, relatedbh, runfields[1]) In this case, the displayed data from both is identical -- the logging line comes back as: INFO:Related borehole_id is testbh3, of_borehole is testbh3 So the data type is the same, and the content appears to be the same. So why would there be a foreign key mismatch? Is it possible that there is some invisible code in the string which isn't being detected by the logging command? Is this just a quirk of the Sqlite3 implementation in Python that demands foreign keys be integers? First thing I'd do, if I'm suspicious of invisible stuff in a string, is to change those %s markers to %r. You'll get a quoted string (so you can see if there's leading/trailing whitespace), any non-ASCII characters will be escaped (assuming this is a byte string in Python 2, which seems to be the case), and control characters like newlines will become escapes too. But I've seen a number of very strange and annoying behaviours out of SQLite as regards foreign keys. It seems that sometimes integrity checks just aren't being done, and I don't know why. Can you switch to a PostgreSQL back-end to see if the problem (a) suddenly disappears, (b) suddenly appears at a completely different point, or (c) now has a more informative error message? Chances are all you need to do is change your import and connection setup, and all the rest will work just the same. By the way, naming convention: I prefer to use id only when it's actually a numeric ID. For something like this, I'd call it name, since that's what it is. But that won't be affecting your foreign key. ChrisA Well that DID make a difference! I used the %r marker, and the logger line gave me back: INFO:Related borehole_id is u'testbh3', of_borehole is 'testbh3' So it looks like I need to change my foreign key string to a unicode string. I'll be working on that... -- https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sunday, November 23, 2014 9:06:03 AM UTC+5:30, Seymore4Head wrote:
Now I am trying to add a dictionary, but it is broke too.
How do I fix:
class RPS:
key={0:rock, 1:paper,2:scissors};
def __init__(self):
self.throw=random.randrange(3)
self.key=key[self.throw]
Maybe you want this?
class RPS:
key ={0:rock, 1:paper, 2:scissors}
def __init__(self):
self.throw=random.randrange(3)
self.key=RPS.key[self.throw]
Whether reusing 'key' like this is a good idea is another matter!
--
https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sat, 22 Nov 2014 22:52:33 -0500, Joel Goldstick
joel.goldst...@gmail.com wrote:
On Sat, Nov 22, 2014 at 10:35 PM, Seymore4Head
Seymore4Head@hotmail.invalid wrote:
On Sat, 22 Nov 2014 22:14:21 -0500, Ned Batchelder
n...@nedbatchelder.com wrote:
On 11/22/14 9:47 PM, Seymore4Head wrote:
What do I need to do to make a and b have different values?
import random
class RPS:
throw=random.randrange(3)
a=RPS
b=RPS
This simply makes a and b into other names for the class RPS. To
instantiate a class to make an object, you have to call it:
a = RPS()
b = RPS()
-
I tried:
class RPS:
def __init__(self):
self.throw=random.randrange(3)
AttributeError: type object 'RPS' has no attribute 'throw'
This is the right way to define the class (almost: in Py 2, you should
derive from object). Once you make an object from it, you will have what
you want:
class RPS(object):
def __init__(self):
self.throw = random.randrange(3)
a = RPS()
b = RPS()
print a.throw
print b.throw
Now I am trying to add a dictionary, but it is broke too.
How do I fix:
class RPS:
key={0:rock, 1:paper,2:scissors};
def __init__(self):
self.throw=random.randrange(3)
self.key=key[self.throw]
--
https://mail.python.org/mailman/listinfo/python-list
can you please show traceback and output?
Traceback (most recent call last):
File C:\Documents and Settings\Administrator\Desktop\rps.py, line
7, in module
a=RPS()
File C:\Documents and Settings\Administrator\Desktop\rps.py, line
6, in __init__
self.key=key[self.throw]
NameError: name 'key' is not defined
--
https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sat, 22 Nov 2014 19:55:08 -0800 (PST), Rustom Mody
rustompm...@gmail.com wrote:
On Sunday, November 23, 2014 9:06:03 AM UTC+5:30, Seymore4Head wrote:
Now I am trying to add a dictionary, but it is broke too.
How do I fix:
class RPS:
key={0:rock, 1:paper,2:scissors};
def __init__(self):
self.throw=random.randrange(3)
self.key=key[self.throw]
Maybe you want this?
class RPS:
key ={0:rock, 1:paper, 2:scissors}
def __init__(self):
self.throw=random.randrange(3)
self.key=RPS.key[self.throw]
Whether reusing 'key' like this is a good idea is another matter!
That works.
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Re: SQLite3 in Python 2.7 Rejecting Foreign Key Insert
On 11/22/2014 08:54 PM, llanitedave wrote: Well that DID make a difference! I used the %r marker, and the logger line gave me back: INFO:Related borehole_id is u'testbh3', of_borehole is 'testbh3' So it looks like I need to change my foreign key string to a unicode string. I'll be working on that... Or manually encode it to a UTF-8 byte string (just call .encode() on it). Sqlite probably only knows about UTF-8 when it comes to unicode. -- https://mail.python.org/mailman/listinfo/python-list
Re: SQLite3 in Python 2.7 Rejecting Foreign Key Insert
On Sun, Nov 23, 2014 at 3:58 PM, Michael Torrie torr...@gmail.com wrote: On 11/22/2014 08:54 PM, llanitedave wrote: Well that DID make a difference! I used the %r marker, and the logger line gave me back: INFO:Related borehole_id is u'testbh3', of_borehole is 'testbh3' So it looks like I need to change my foreign key string to a unicode string. I'll be working on that... Or manually encode it to a UTF-8 byte string (just call .encode() on it). Sqlite probably only knows about UTF-8 when it comes to unicode. Since it was a byte string sent to the database and a Unicode string coming back, the solution would be to .decode() the byte string. However, I doubt that's the issue; that's being done for you implicitly by the lower-level connections. Also, in Python 2: u'testbh3' == 'testbh3' True So that's not your primary problem. You could try that, but I doubt it'll solve anything for you. Are you able to switch to Python 3, though? If you are, Unicode issues tend to be a lot easier to resolve there. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
Ethan Furman wrote: On 11/21/2014 08:43 PM, Steven D'Aprano wrote: random...@fastmail.us wrote: I think I tried on at least one python version and printing the tuple crashed with a recursion depth error, since it had no special protection for this case the way list printing does. It works fine now (Python 3.3). py L = [] py t = (L, None) py L.append(L) py L.append(t) # For good measure. py print(t) ([[...], (...)], None) This is a tuple in a list in a tuple, not a tuple in a tuple. Really? I hadn't noticed. *wink* It's still a tuple in itself, recursively, and the tuple to str conversion routine still has to deal with the fact. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: I have no class
On Sun, Nov 23, 2014 at 3:15 PM, Seymore4Head
Seymore4Head@hotmail.invalid wrote:
Traceback (most recent call last):
File C:\Documents and Settings\Administrator\Desktop\rps.py, line
7, in module
a=RPS()
File C:\Documents and Settings\Administrator\Desktop\rps.py, line
6, in __init__
self.key=key[self.throw]
NameError: name 'key' is not defined
This information is far more helpful than it is broke. Note how it
says that the name 'key' is not defined? You're expecting that it
would be defined, because you defined it a few lines earlier. So
here's a more useful way to ask the question:
-- cut --
I'm trying to use a dictionary to translate throw numbers into
descriptions, but even though the dictionary has been defined, Python
is telling me it hasn't.
import random
class RPS:
key={0:rock, 1:paper,2:scissors};
def __init__(self):
self.throw=random.randrange(3)
self.key=key[self.throw]
a=RPS()
Traceback (most recent call last):
File C:\Documents and Settings\Administrator\Desktop\rps.py, line
7, in module
a=RPS()
File C:\Documents and Settings\Administrator\Desktop\rps.py, line
6, in __init__
self.key=key[self.throw]
NameError: name 'key' is not defined
It seems to me that 'key' is defined on line 3. Can anyone explain
what's happening here? Thanks!
-- cut --
Note that I've posted the *entire* code of your script (it's a
reconstruction, but I suspect it's fairly close; there might be more
code after that, but it's not affecting anything), and included the
traceback in the first message, rather than waiting for someone to ask
for it.
Armed with this information, someone can tell you:
1) Python's namespacing rules mean that 'key' is a part of the RPS
class, and can be referred to as 'self.key' or as 'RPS.key'
2) Use of 'self.key' for the textual form of the throw is shadowing
the first of those reference names (but it's a poor name anyway)
3) A list would work just as well as a dictionary here, since your
indices are sequential and start from zero
4) There's another function in the random module which can do both of
your steps at once.
Thank you for helping us help you help us all!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: SQLite3 in Python 2.7 Rejecting Foreign Key Insert
On Saturday, November 22, 2014 9:41:55 PM UTC-8, Chris Angelico wrote: On Sun, Nov 23, 2014 at 3:58 PM, Michael Torrie wrote: On 11/22/2014 08:54 PM, llanitedave wrote: Well that DID make a difference! I used the %r marker, and the logger line gave me back: INFO:Related borehole_id is u'testbh3', of_borehole is 'testbh3' So it looks like I need to change my foreign key string to a unicode string. I'll be working on that... Or manually encode it to a UTF-8 byte string (just call .encode() on it). Sqlite probably only knows about UTF-8 when it comes to unicode. Since it was a byte string sent to the database and a Unicode string coming back, the solution would be to .decode() the byte string. However, I doubt that's the issue; that's being done for you implicitly by the lower-level connections. Also, in Python 2: u'testbh3' == 'testbh3' True So that's not your primary problem. You could try that, but I doubt it'll solve anything for you. Are you able to switch to Python 3, though? If you are, Unicode issues tend to be a lot easier to resolve there. ChrisA You're right. It ultimately didn't make a difference. And it makes sense that it wouldn't have, because when I did a query using the same field that got rejected by the foreign key, the query was successful. The application was working correctly earlier (meaning that I could enter and retrieve data with it; being a strictly user application it didn't allow deletes from the GUI), and then I discovered (while cleaning up the user documentation) that I'd neglected to include a couple of relatively important database fields. Because of SQLite's limited ALTER TABLE capabilities, that mean I had to recreate the tables to add the fields, and in doing so noticed that the table in question didn't even have the foreign key constraint defined. So ever since I defined that constraint, it hasn't let me save any records on that table from Python. Although, as I said, when entering the same data through the Sqliteman application, it works fine. That's why I suspected that the problem might be in the Python API for SQLite3. As for Python3, that's a future possibility. My next step was to expand the functionality of this particular app, which is intended for use in the field on a tablet or laptop, to a web-app using Django 1.7. WxPython was really a way to get my feet wet on it. The Django version is using Python 3.4 and Postgresql 9.3.4, and it's still in the early stages -- I broke off of it to correct this mess. It's in the back of my head to go back to the field version at some point with Python3 and PyQt, but it is not this day. Anyway, if I can't get this thing straightened out, I may have to just remove the foreign key constraint and rely on application logic to ensure my data integrity. :( I do appreciate the help, though Chris. If nothing else, you've showed me some directions that I needed some extra learning in. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
random...@fastmail.us wrote: On Fri, Nov 21, 2014, at 23:38, Steven D'Aprano wrote: I really don't understand what bothers you about this. In Python, we have Unicode strings and byte strings. In computing in general, strings can consist of Unicode characters, ASCII characters, Tron characters, EBCDID characters, ISO-8859-7 characters, and literally dozens of others. It boogles my mind that you are so opposed to being explicit about what sort of string we are dealing with. I think he means that it should be implementation-defined with an API that does not allow programs to make assumptions about the encoding, like C. To allow for implementations that use a different character set. Python is not C, and doesn't make every second thing undefined behaviour. If Python treated the character set as an implementation detail, the programmer would have no way of knowing whether s = uö is legal or not, since you cannot know whether or not ö is a supported character in the running Python. It might work on your system, and fail for other people. That is worse than the old distinction between narrow and wide builds. It would be a lazy and stupid design, and especially stupid since there really in no good alternative to Unicode today. ASCII is not even sufficient for American English, the whole Windows code page idea is a horrible mess, none of the legacy encodings are suitable for more than a tiny fraction of the world. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: SQLite3 in Python 2.7 Rejecting Foreign Key Insert
On Sun, Nov 23, 2014 at 5:08 PM, llanitedave
llanited...@birdandflower.com wrote:
The application was working correctly earlier (meaning that I could enter
and retrieve data with it; being a strictly user application it didn't allow
deletes from the GUI), and then I discovered (while cleaning up the user
documentation) that I'd neglected to include a couple of relatively important
database fields. Because of SQLite's limited ALTER TABLE capabilities, that
mean I had to recreate the tables to add the fields, and in doing so noticed
that the table in question didn't even have the foreign key constraint
defined. So ever since I defined that constraint, it hasn't let me save any
records on that table from Python. Although, as I said, when entering the
same data through the Sqliteman application, it works fine. That's why I
suspected that the problem might be in the Python API for SQLite3.
Entirely possible. I never did track down the actual cause of the
SQLite3 issues my students were having; though I suspect it's not
purely a Python API issue. I tried to demonstrate the concept of
foreign keys using the sqlite3 command line tool, and did a sequence
of commands which ought to have failed, but didn't. Let's see if I can
recreate this:
rosuav@sikorsky:~$ sqlite3
SQLite version 3.7.13 2012-06-11 02:05:22
Enter .help for instructions
Enter SQL statements terminated with a ;
sqlite create table foo (val text primary key);
sqlite create table bar (val text references foo on delete set null);
sqlite insert into foo values ('asdf');
sqlite insert into bar values ('asdf');
sqlite insert into bar values ('qwer');
sqlite select * from foo;
asdf
sqlite select * from bar;
asdf
qwer
sqlite delete from foo;
sqlite select * from foo;
sqlite select * from bar;
asdf
qwer
So the foreign key is being completely ignored. If I do the same
commands in PostgreSQL, I get errors at appropriate places:
rosuav@sikorsky:~$ psql
psql (9.3.5)
Type help for help.
rosuav= create table foo (val text primary key);
CREATE TABLE
rosuav= create table bar (val text references foo on delete set null);
CREATE TABLE
rosuav= insert into foo values ('asdf');
INSERT 0 1
rosuav= insert into bar values ('asdf');
INSERT 0 1
rosuav= insert into bar values ('qwer');
ERROR: insert or update on table bar violates foreign key
constraint bar_val_fkey
DETAIL: Key (val)=(qwer) is not present in table foo.
rosuav= select * from foo;
val
--
asdf
(1 row)
rosuav= select * from bar;
val
--
asdf
(1 row)
rosuav= delete from foo;
DELETE 1
rosuav= select * from foo;
val
-
(0 rows)
rosuav= select * from bar;
val
-
(1 row)
PostgreSQL is a lot more chatty, but what's significant here is that
it won't let me insert into the referring table when there's no row in
the referent. Also, when I delete the referred-to row, the referring
row's key gets correctly set to NULL (like I specified in the
constraint definition).
I don't know if there's a way to tell SQLite hey, I want you to
actually take notice of foreign keys, tyvm, as there's nothing
obvious in the .help command output; but even if there is, I don't
know why that isn't the default. Maybe there can be a way to say
ignore foreign key constraints for efficiency, but frankly, I'd
rather have constraints actually checked - if you want to cheat them
away, actually drop the constraints, don't have the database silently
ignore them.
As for Python3, that's a future possibility. My next step was to expand the
functionality of this particular app, which is intended for use in the field
on a tablet or laptop, to a web-app using Django 1.7. WxPython was really a
way to get my feet wet on it. The Django version is using Python 3.4 and
Postgresql 9.3.4, and it's still in the early stages -- I broke off of it to
correct this mess.
It's in the back of my head to go back to the field version at some point
with Python3 and PyQt, but it is not this day.
Cool. There are several GUI toolkits for Python, and I know multiple
of them do support Py3; I can't say which is the best, as I don't do
my GUI programming in Python generally. But definitely try to use
Python 3 if you can; and try to use PostgreSQL if you can, too.
SQLite3 may be the light-weight option, but as you're seeing, it does
sometimes take shortcuts; switching to a more full-featured database
may be worth doing permanently, or at least for development (think of
it like turning on a bunch of assertions).
Anyway, if I can't get this thing straightened out, I may have to just remove
the foreign key constraint and rely on application logic to ensure my data
integrity. :(
I do appreciate the help, though Chris. If nothing else, you've showed me
some directions that I needed some extra learning in.
My pleasure! Databasing is well worth studying up on; the better laid
out your table structure, the easier your coding will be - and more
importantly, the easier your data debugging will be. A quick
Re: PyWart: Python's import statement and the history of external dependencies
Chris Angelico wrote: On Sat, Nov 22, 2014 at 11:25 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Ian Kelly wrote: - It's hard to keep track of what modules are in the standard library. Which of the following is *not* in Python 3.3's std lib? No cheating by looking them up.) os2emxpath, wave, sndheader, statslib, poplist, plist, pickletools, picklelib, path, cgi, cgitb, copylib, xpath Okay, here's my guesses. os2emxpath: In the stdlib, but more often accessed as os.path while running under OS/2 Correct. wave: Not in the stdlib, though I'd avoid the name anyway. Incorrect. The wave module is for manipulating .wav files. sndheader: Not in the stdlib - probably on PyPI though Correct. It is actually spelled sndhdr. poplist, plist, pickletools, picklelib: I suspect PyPI, not stdlib, but could be wrong There's a pickletools, but not picklelib. plist is actually spelled plistlib, and there is poplib, not poplist. path: Not in the stdlib (there's os.path and I doubt there'd be both) cgi, cgitb: In the stdlib Correct. copylib: No idea, could be either way. Spelled copy, not copylist. xpath: I'll guess this as not being present. Correct. Not bad, but as you can see, the naming convensions are all over the place. It's easy to accidentally shadow the std lib. [...] That would be horrible. But here's an alternative which is less horrible and maybe even useful. There's still a single process-wide search path, but there's a second per-module search path which is searched first. By default it's empty. So a module can define it's own extra search path: __path__ = ['look/here', 'and/here'] import something without affecting any other modules. That's what Rick said first, and then said that if you're going to be explicit, you should do the job properly and not have _any_ implicit paths. Rick should ask himself why virtually every single language, from compiled languages like Ada, C, Pascal and Java, to interpreted languages like bash, all use search paths instead of explicit paths. Hint: the answer is not that every single language designer in the world is a moron. Thing is, though, it still breaks the sys.modules concept. Either __path__ is ignored if the module was found in sys.modules Good point. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sun, Nov 23, 2014 at 5:17 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If Python treated the character set as an implementation detail, the programmer would have no way of knowing whether s = uö is legal or not, since you cannot know whether or not ö is a supported character in the running Python. It might work on your system, and fail for other people. That is worse than the old distinction between narrow and wide builds. It would be a lazy and stupid design, and especially stupid since there really in no good alternative to Unicode today. ASCII is not even sufficient for American English, the whole Windows code page idea is a horrible mess, none of the legacy encodings are suitable for more than a tiny fraction of the world. (Code pages aren't a Windows concept, of course, though I guess that's the main place where they're found on PCs today.) The only trouble with enforcing Unicode is Japanese encodings and the whole Han unification debate. Ultimately, you have to pick a side: are you siding with those who say there are fewer characters with multiple forms, or with those who say there are more distinct characters? If the former, go with Unicode. If the latter, be prepared to do heaps of work yourself, and probably be stuck with supporting only Japanese, because encodings like Shift-JIS aren't going to be able to represent Scandinavian text. Me, I'm siding with Unicode. The politicking of Han unification doesn't interest me, so I'm happy to accept a position that says that they're all the same character, just as the Roman letter A can be used in English, Italian, German, Swedish, etc, etc, etc (maybe with some combining characters for diacriticals). That gives me access to all the world's languages with a single character set and some trustworthy encodings. I think it's a fine trade-off: philosophy I don't care about versus correctness in my code. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Sun, Nov 23, 2014, at 00:59, Steven D'Aprano wrote: It works fine now (Python 3.3). py L = [] py t = (L, None) py L.append(L) py L.append(t) # For good measure. py print(t) ([[...], (...)], None) This is a tuple in a list in a tuple, not a tuple in a tuple. Really? I hadn't noticed. *wink* It's still a tuple in itself, recursively, and the tuple to str conversion routine still has to deal with the fact. Does it, or does it punt to the list to str routine? Anyway, on python 2.7, print and str do not work the same way for tuples. I'm remembering more about this issue now, and it was _strictly_ on print, not on str. t ([[...], ([...], None)], None) print(t) ([[...], ([...], None)], None) str(t) '([[...], (...)], None)' Notice that print never does (...), only [...]. And if it never finds a [...]? -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Sunday, November 23, 2014 12:00:15 PM UTC+5:30, Steven D'Aprano wrote: Rick should ask himself why virtually every single language, from compiled languages like Ada, C, Pascal and Java, to interpreted languages like bash, all use search paths instead of explicit paths. Hint: the answer is not that every single language designer in the world is a moron. In all fairness to Rick I can think of two languages -- Erlang and Emacs-lisp. They probably dont do what he wants (I dont really know what he wants -- his verbiage is too much for me to get through) however they come close. Erlang warns about shadowing system-names Elisp has a function -- list-load-path-shadows -- that informs about all shadowings in the system. In a way this makes sense because for a system to warn about shadowing is a trivial cost. For a programmer to keep track of which toes are being stepped on is an error-prone headache. -- https://mail.python.org/mailman/listinfo/python-list
Re: SQLite3 in Python 2.7 Rejecting Foreign Key Insert
On Saturday, November 22, 2014 10:32:30 PM UTC-8, Chris Angelico wrote:
On Sun, Nov 23, 2014 at 5:08 PM, llanitedave wrote:
The application was working correctly earlier (meaning that I could enter
and retrieve data with it; being a strictly user application it didn't
allow deletes from the GUI), and then I discovered (while cleaning up the
user documentation) that I'd neglected to include a couple of relatively
important database fields. Because of SQLite's limited ALTER TABLE
capabilities, that mean I had to recreate the tables to add the fields, and
in doing so noticed that the table in question didn't even have the foreign
key constraint defined. So ever since I defined that constraint, it hasn't
let me save any records on that table from Python. Although, as I said,
when entering the same data through the Sqliteman application, it works
fine. That's why I suspected that the problem might be in the Python API
for SQLite3.
Entirely possible. I never did track down the actual cause of the
SQLite3 issues my students were having; though I suspect it's not
purely a Python API issue. I tried to demonstrate the concept of
foreign keys using the sqlite3 command line tool, and did a sequence
of commands which ought to have failed, but didn't. Let's see if I can
recreate this:
rosuav@sikorsky:~$ sqlite3
SQLite version 3.7.13 2012-06-11 02:05:22
Enter .help for instructions
Enter SQL statements terminated with a ;
sqlite create table foo (val text primary key);
sqlite create table bar (val text references foo on delete set null);
sqlite insert into foo values ('asdf');
sqlite insert into bar values ('asdf');
sqlite insert into bar values ('qwer');
sqlite select * from foo;
asdf
sqlite select * from bar;
asdf
qwer
sqlite delete from foo;
sqlite select * from foo;
sqlite select * from bar;
asdf
qwer
So the foreign key is being completely ignored. If I do the same
commands in PostgreSQL, I get errors at appropriate places:
rosuav@sikorsky:~$ psql
psql (9.3.5)
Type help for help.
rosuav= create table foo (val text primary key);
CREATE TABLE
rosuav= create table bar (val text references foo on delete set null);
CREATE TABLE
rosuav= insert into foo values ('asdf');
INSERT 0 1
rosuav= insert into bar values ('asdf');
INSERT 0 1
rosuav= insert into bar values ('qwer');
ERROR: insert or update on table bar violates foreign key
constraint bar_val_fkey
DETAIL: Key (val)=(qwer) is not present in table foo.
rosuav= select * from foo;
val
--
asdf
(1 row)
rosuav= select * from bar;
val
--
asdf
(1 row)
rosuav= delete from foo;
DELETE 1
rosuav= select * from foo;
val
-
(0 rows)
rosuav= select * from bar;
val
-
(1 row)
PostgreSQL is a lot more chatty, but what's significant here is that
it won't let me insert into the referring table when there's no row in
the referent. Also, when I delete the referred-to row, the referring
row's key gets correctly set to NULL (like I specified in the
constraint definition).
I don't know if there's a way to tell SQLite hey, I want you to
actually take notice of foreign keys, tyvm, as there's nothing
obvious in the .help command output; but even if there is, I don't
know why that isn't the default. Maybe there can be a way to say
ignore foreign key constraints for efficiency, but frankly, I'd
rather have constraints actually checked - if you want to cheat them
away, actually drop the constraints, don't have the database silently
ignore them.
As for Python3, that's a future possibility. My next step was to expand
the functionality of this particular app, which is intended for use in the
field on a tablet or laptop, to a web-app using Django 1.7. WxPython was
really a way to get my feet wet on it. The Django version is using Python
3.4 and Postgresql 9.3.4, and it's still in the early stages -- I broke off
of it to correct this mess.
It's in the back of my head to go back to the field version at some point
with Python3 and PyQt, but it is not this day.
Cool. There are several GUI toolkits for Python, and I know multiple
of them do support Py3; I can't say which is the best, as I don't do
my GUI programming in Python generally. But definitely try to use
Python 3 if you can; and try to use PostgreSQL if you can, too.
SQLite3 may be the light-weight option, but as you're seeing, it does
sometimes take shortcuts; switching to a more full-featured database
may be worth doing permanently, or at least for development (think of
it like turning on a bunch of assertions).
Anyway, if I can't get this thing straightened out, I may have to just
remove the foreign key constraint and rely on application logic to ensure
my data integrity. :(
I do appreciate the help, though Chris. If nothing else, you've showed me
some directions that I needed some extra learning in.
My pleasure! Databasing is
Re: PyWart: Python's import statement and the history of external dependencies
On Sun, Nov 23, 2014 at 5:30 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Chris Angelico wrote: Okay, here's my guesses. os2emxpath: In the stdlib, but more often accessed as os.path while running under OS/2 Correct. I'm in a special position here, as I actually have an OS/2 system, and have used Python on it. So I know about the particular obscure system that you happened to pick there. Now, if you'd said amigapath, I wouldn't have known. [chomp a few correct and a few wrong, here and there] Not bad, but as you can see, the naming convensions are all over the place. It's easy to accidentally shadow the std lib. Agreed. There's no way to guarantee that you aren't shadowing someone else's module, except by namespacing your own - either putting your name at the beginning of every file name (fredfoobar_calendar) or by making a package (fredfoobar.calendar). It would be nice, though, to be able to *detect* shadowing. Is there a way (maybe through importlib) to ask Python to enumerate every file that could be found when attempting to import calendar? Something like this: import importlib importlib.find_all_modules(calendar) ['calendar.py', '/usr/local/lib/python3.5/calendar.py'] That would be a useful feature, if it doesn't already exist. If it does, it could do with a bit more visibility - poking around on Google and interactively with help(importlib) etc didn't reveal it to me. That's what Rick said first, and then said that if you're going to be explicit, you should do the job properly and not have _any_ implicit paths. Rick should ask himself why virtually every single language, from compiled languages like Ada, C, Pascal and Java, to interpreted languages like bash, all use search paths instead of explicit paths. Hint: the answer is not that every single language designer in the world is a moron. Maybe they are. Maybe Rick's just so amazingly brilliant that he, alone among all language designers, has figured this out. Maybe it's time for his fork of Python to sweep the world with its incredible solutions to massively prevalent problems! While it *is* possible for every language in the world to get something wrong, there's usually a few around the place that get it right. Until Python 3.3, most popular languages got Unicode support either wrong (using UTF-16 being the most common wrongness) or inefficient (using UTF-32), or just didn't have any at all (bytes everywhere). Could someone look at the state of world programming languages and say Everyone uses UTF-16, and not every language designer in the world is a moron, therefore UTF-16 must be the right thing to do? No, because Haskell, Scheme, Pike, and bash all had it right, already. Sure, they're not the most-used languages in the world, but they certainly are used (bash plenty, though to be honest, not many people use bash scripts for Unicode heavy-lifting), and they prove that UTF-16 isn't the only way to go. So, where are the languages that use explicit paths? Show us why they're so great, using actual production code. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Sun, Nov 23, 2014 at 5:30 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: wave: Not in the stdlib, though I'd avoid the name anyway. Incorrect. The wave module is for manipulating .wav files. sndheader: Not in the stdlib - probably on PyPI though Correct. It is actually spelled sndhdr. Just out of curiosity, why does the stdlib need modules for manipulating .wav and other sound files, but we have to go to PyPI to get a PostgreSQL client? It's a queer world... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
Chris Angelico ros...@gmail.com writes: Just out of curiosity, why does the stdlib need modules for manipulating .wav and other sound files, but we have to go to PyPI to get a PostgreSQL client? It's a queer world... I would venture the follow two reasons, either of which is sufficient to explain the difference: * Modules enter the standard library only if they are judged both to be good quality *and* have a credible promise to continue to maintain them in the standard library on an ongoing basis. If one module has reliable maintainers offering to do the work and another does not, the latter will not be a candidate for inclusion in the Python standard library. * Modules enter the standard library only if their feature set is stable enough that they can remain essentially unchanged, feature-wise, for many years and still be widely useful. For a data stream format (like WAV and other mature formats), a module working well today is likely to work just as well for the same purpose in several years's time, long enough for today's Python to go through its full life cycle of support. PostgreSQL is a full-blown system that is itself under continual development, and its APIs continually change to match. Whatever Python API for PostgreSQL gets put into the standard library today is likely to be obsolete long before today's version of Python gets close to ending support. That makes it a poor candidate for inclusion in the standard library. -- \ “The generation of random numbers is too important to be left | `\to chance.” —Robert R. Coveyou | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Sun, Nov 23, 2014 at 6:43 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: For a data stream format (like WAV and other mature formats), a module working well today is likely to work just as well for the same purpose in several years's time, long enough for today's Python to go through its full life cycle of support. PostgreSQL is a full-blown system that is itself under continual development, and its APIs continually change to match. Whatever Python API for PostgreSQL gets put into the standard library today is likely to be obsolete long before today's version of Python gets close to ending support. That makes it a poor candidate for inclusion in the standard library. That makes sense, as differences go. Though if wave and sndhdr were currently PyPI-only and someone came to python-ideas/python-dev saying These modules ought to be in the standard library, I doubt they'd get a huge amount of support. Of course, since they're currently in the stdlib, there's absolutely no reason to *remove* them, but any similar modules are likely to stay pip-gettable rather than autoincluded. In contrast, something like Lib/email.py is providing functionality that heaps of Python scripts want - sending or parsing emails is pretty common, so it makes good sense to have that in the stdlib. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
[issue22915] sax.parser cannot get xml data from a subprocess pipe
Changes by Serhiy Storchaka storch...@gmail.com: -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19980] Improve help('non-topic') response
Mark Lawrence added the comment: Did I test the last patch? I would hope so but I simply can't remember as it's nearly four months ago, sorry :( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22869] Split pylifecycle.c out from pythonrun.c
Nick Coghlan added the comment: Thanks folks - Zach's right, that wasn't supposed to move. I missed the second copy in pylifecycle.c because it's all #ifdef'ed out on Linux, so the linker didn't complain about the duplication. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22869 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22915] sax.parser cannot get xml data from a subprocess pipe
Changes by Avneesh Chadha avneesh.cha...@gmail.com: -- nosy: +Avneesh.Chadha ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21815] imaplib truncates some untagged responses
Lita Cho added the comment: Here is the patch merged together. I apologize for not getting it to you sooner. -- Added file: http://bugs.python.org/file37245/imaplib_bracket_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21815 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22638] ssl module: the SSLv3 protocol is vulnerable (POODLE attack)
Federico Ceratto added the comment: FYI Debian dropped ssl.PROTOCOL_SSLv3 from Python 2.7 in the upcoming Jessie release: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768611 -- nosy: +federico3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22638 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22638] ssl module: the SSLv3 protocol is vulnerable (POODLE attack)
Antoine Pitrou added the comment: FYI Debian dropped ssl.PROTOCOL_SSLv3 from Python 2.7 in the upcoming Jessie release: This is not really what the Debian patch does. What it does is allow the ssl module to compile if SSLv3 is disabled in the OpenSSL build. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22638 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19980] Improve help('non-topic') response
Zachary Ware added the comment: In that case, it would be good to make sure it still applies and passes the tests. Last time I tried it didn't, and I was called away before I could leave a note to that effect (for which I am sorry). However, I don't have a strong enough opinion on this issue for me to have fixed your patch or even to have kept it in mind to come back to later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1610654] cgi.py multipart/form-data
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1610654 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21815] imaplib truncates some untagged responses
Changes by Berker Peksag berker.pek...@gmail.com: -- versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21815 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22916] Interpreter segfault on attempted tab complete
New submission from Kevin Smith: I am getting a segmentation fault in the interpreter when trying to tab complete options for a module. I am running python 3.4.2 on Arch Linux. Python 3.4.2 (default, Oct 8 2014, 13:44:52) [GCC 4.9.1 20140903 (prerelease)] on linux Type help, copyright, credits or license for more information. import sfml as sf t = sf.Texture.from_file (sprites.png) s = sf.Sprite (t) s.Segmentation fault When I type s. then push tab to complete available options the interpreter segfaults. This is with python-sfml-1.3-4 from the Arch repositories. Tab completion for built-in types seems to work fine. -- messages: 231520 nosy: FazJaxton priority: normal severity: normal status: open title: Interpreter segfault on attempted tab complete type: crash versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22916 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22834] Unexpected FileNotFoundError when current directory is removed
Roundup Robot added the comment: New changeset d065e6474b67 by Zachary Ware in branch 'default': Issue #22834: cwd can't not exist on Windows, skip the test https://hg.python.org/cpython/rev/d065e6474b67 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22834 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22638] ssl module: the SSLv3 protocol is vulnerable (POODLE attack)
Donald Stufft added the comment: Right, they did that because Debian has disabled SSLv3 in OpenSSL in Jessie. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22638 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22638] ssl module: the SSLv3 protocol is vulnerable (POODLE attack)
Antoine Pitrou added the comment: If that's the case, then I agree we can backport e971f3c57502 to the bugfix branches. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22638 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22638] ssl module: the SSLv3 protocol is vulnerable (POODLE attack)
Donald Stufft added the comment: Yea see: http://sources.debian.net/src/openssl/1.0.2~beta3-1/debian/rules/#L29 The configure options they are running with are: no-idea no-mdc2 no-rc5 no-zlib enable-tlsext no-ssl2 no-ssl3 no-ssl3-method enable-unit-test -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22638 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22914] Rewrite of Python 2/3 porting HOWTO
Brett Cannon added the comment: I removed a bunch of sections for two reasons. One is they are redundant. If you follow the HOWTO and actually read What's New then you will get a bunch of those same details anyway. The tools will also handle the details for you and so you really don't have to worry about them (and they document them already). And Pylint will warn you when you have not taken care of them. So having a fourth place listing the fact you need to subclass object is simply a waste. Second is accidental FUD. If you have a huge list of things to watch out for then you are going to end up scaring people off by making them feel intimidated at the work ahead of them. But if you reframe the whole thing as just follow this TODO list and you will be fine you can make people realize that most things are simply not a big deal. But the point about telling people to run with -bb and -3 and a couple of minor comments are valid and I will toss some of them back in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments properly
Steve Dower added the comment: Nosying the other Windows guys - seems like the ctypes nosy list is inactive, and this only affects MSVC. -- nosy: +tim.golden, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22733 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22917] Calculating problem
New submission from heme: Hi guys I am very new to this, (just started my first lines today) so I am using a book to learn Python. BUT there is something wrong: This is my program (from the book): # This is not quite true outside of USA # and is based on my dim memories of my younger years print(Firstish Grade) print(1 + 1 =, 1 + 1) print(2 + 4 =, 2 + 4) print(5 - 2 =, 5 - 2) print() print(Thirdish Grade) print(243 - 23 =, 243 - 23) print(12 * 4 =, 12 * 4) print(12 / 3 =, 12 / 3) print(13 / 3 =, 13 // 3, R, 13 % 3) print() print(Junior High) print(123.56 - 62.12 =, 123.56 - 62.12) print((4 + 3) * 2 =, (4 + 3) * 2) print(4 + 3 * 2 =, 4 + 3 * 2) print(3 ** 2 =, 3 ** 2) and this is the programs answer: Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32 Type copyright, credits or license() for more information. RESTART Firstish Grade 1 + 1 = 2 2 + 4 = 6 5 - 2 = 3 Thirdish Grade 243 - 23 = 220 12 * 4 = 48 12 / 3 = 4.0 13 / 3 = 4 R 1 Junior High 123.56 - 62.12 = 61.445 (4 + 3) * 2 = 14 4 + 3 * 2 = 10 3 ** 2 = 9 As you can see, print(123.56 - 62.12 =, 123.56 - 62.12) is not = 61.445 so my guess is that the interpreter has a malfunction. My pc is a compaq mini 110 running (walking;-)) windows xp srv pack 3 in a std. config. brg Henning Mentz - Denmark -- messages: 231527 nosy: heme priority: normal severity: normal status: open title: Calculating problem ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22917 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22917] Calculating problem
SilentGhost added the comment: Hi Henning, this is not a bug. This is to do with how floating point numbers represented in computers. I'd suggest https://en.wikipedia.org/wiki/IEEE_floating_point as a starting point. Briefly, due to binary base that the computers operate on, not every number can be stored/represented precisely. In any case there are plenty of other information online that you can find useful, the easiest solution is to output correctly formatted strings corresponding to your answers. Good luck. -- nosy: +SilentGhost resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22917 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22918] Doc for __iter__ makes inexact comment about dict.__iter__
New submission from Éric Araujo: https://docs.python.org/3/reference/datamodel#object.__iter__ This method should return a new iterator object that can iterate over all the objects in the container. For mappings, it should iterate over the keys of the container, and should also be made available as the method keys(). In 3.x, d.__iter__() is not equivalent to d.keys() but to iter(d.keys()). -- assignee: docs@python components: Documentation keywords: easy messages: 231529 nosy: docs@python, eric.araujo priority: normal severity: normal stage: needs patch status: open title: Doc for __iter__ makes inexact comment about dict.__iter__ versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22916] Interpreter segfault on attempted tab complete
Ned Deily added the comment: This is very unlikely to be a problem in Python itself, rather a problem with the third-party python-sfml package or a build interaction issue. Have you asked on either an Arch or a python-sfml list about this? What happens if you you try dir(s) instead? -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22916 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
New submission from Steve Dower: I've basically finished the core of the work to refresh the PCBuild project files and support building with VS 2015, and I believe it's ready to merge in. Though the title says VS 2015, builds will work fine with VS 2010 and VS 2013 (and probably VS 2012, but I didn't try it). Even so, I've copied the old project files into PC/VS10.0, though I'd be happy to just forget them. I suspect Tools/msi/msi.py will stop working with this change. My replacement installer is not ready yet. If anyone's particularly concerned about msi.py then I can try and restore it before checking this in, but I'm 99.9% certain it won't be used for 3.5, so I don't see the point. I've attached two patches, one with all the changes and the other with the highlights - the diff between the diffs are most of the project files and the added/deleted files. I imagine practically everyone will have a better time viewing the changes in their own hg tools, so the changes can be pulled from my sandbox with hg pull https://hg.python.org/sandbox/steve.dower -b Projects or viewed at https://hg.python.org/sandbox/steve.dower/shortlog/d08b456124e5. (I'll rebase these as a single commit in default when it goes in.) A few changes that may deserve some more discussion: * Builds for 32-bit now go to PCBuild\win32 instead of PCBuild (the batch file updates should make this transparent) * The project that used to trigger the OpenSSL build is now two projects (libeay, ssleay) that do the build directly, so they may need updating whenever we update the OpenSSL version or change _ssl/_hashlib. I'm obviously happy to track these. (The advantages are proper incremental builds, better debugging, better optimisation - definitely PGO if we turn that back on.) * The posixmodule.c update for Py_Verify_fd may become redundant - the VC14 CRT will include a per-thread function to change the invalid parameter handling, so when that's available we should be able to switch away from this trickery completely. * I changed some GetVersion calls (which no longer behave properly as of Windows 8.1) to use functions from VersionHelpers.h in VS 2013 and later. * build.bat now builds in parallel by default, with '-M' to disable. * PCBuild/readme.txt has been updated as if VS 2015 has already been released. This is not yet true, but I doubt anyone who notices will be particularly confused or upset. -- assignee: steve.dower components: Build, Windows files: projects_highlights.diff keywords: needs review, patch messages: 231531 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Update PCBuild for VS 2015 type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37246/projects_highlights.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Changes by Steve Dower steve.do...@microsoft.com: Added file: http://bugs.python.org/file37247/projects_full.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22916] Interpreter segfault on attempted tab complete
eryksun added the comment: This isn't a bug in Python or tab completion. You can reproduce the fault by referencing s.transformable twice and then deleting both references. The getter for TransformableDrawable.transformable calls wrap_transformable to create a wrapper for the underlying C++ object (self.p_transformable). TransformDrawable https://github.com/Sonkun/python-sfml/blob/v1.3/src/sfml/graphics.pyx#L1175 wrap_transformable https://github.com/Sonkun/python-sfml/blob/v1.3/src/sfml/graphics.pyx#L381 Thus each Transformable wrapper references the same C++ object. Transformable.__dealloc__ in graphics.pyx https://github.com/Sonkun/python-sfml/blob/v1.3/src/sfml/graphics.pyx#L1117 gets Cythonized as __pyx_pf_4sfml_8graphics_13Transformable_2__dealloc__ in graphics.cpp. This executes the C++ delete that segfaults: delete __pyx_v_self-p_this; For example: x = s.transformable y = s.transformable del y Breakpoint 1, __pyx_pf_4sfml_8graphics_13Transformable_2__dealloc__ (__pyx_v_self=0xb774d8c0) at src/sfml/graphics.cpp:21354 21354 delete __pyx_v_self-p_this; (gdb) p __pyx_v_self-p_this $1 = (sf::Transformable *) 0x8695b24 (gdb) c Continuing. del x Breakpoint 1, __pyx_pf_4sfml_8graphics_13Transformable_2__dealloc__ (__pyx_v_self=0xb774d910) at src/sfml/graphics.cpp:21354 21354 delete __pyx_v_self-p_this; (gdb) p __pyx_v_self-p_this $2 = (sf::Transformable *) 0x8695b24 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. -- nosy: +eryksun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22916 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22920] Crash with itertools
New submission from Terry J. Reedy: import itertools l = [] it = itertools.chain.from_iterable(l) l.append(it) next(it) Ian Kelly (python-list, version unspecified) got Segmentation fault (core dumped). With 2.7, 3.4.2, 3.5, I get same in interactive interpreter, the Windows python has stopped working box from console, or subprocess hang with Idle. -- messages: 231534 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: Crash with itertools type: crash versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22920 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22920] Crash with itertools
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22920 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Steve Dower added the comment: Oh, one other thing I just thought of: the current release of nmake (in VS 2015) has a regression that will make TCL and TK fail to build, but I have a workaround for their makefile. OpenSSL also had a problem with VC14 but their fix isn't in the build we've got on svn.python.org. If possible, I'd like to get the workarounds into our sources for those before this is checked in, so that the buildbots (currently there's one that I know of with VS 2015 Preview installed) can pick up those fixes and won't fail because of these. The nmake issue should be fixed for VS 2015 RC and the OpenSSL issue is already fixed (in their 1.1 branch, IIRC). I've attached a patch listing the changes needed. -- Added file: http://bugs.python.org/file37248/fixups.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22920] Crash with itertools.chain.from_iterable
Changes by Terry J. Reedy tjre...@udel.edu: -- title: Crash with itertools - Crash with itertools.chain.from_iterable ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22920 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22920] Crash with itertools.chain.from_iterable
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman resolution: - duplicate status: open - closed superseder: - deeply nested filter segfaults ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22920 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14010] deeply nested filter segfaults
Ethan Furman added the comment: From Terry Reedy in issue22920: -- Ian Kelly (python-list, version unspecified) got Segmentation fault (core dumped). With 2.7, 3.4.2, 3.5, I get same in interactive interpreter, the Windows python has stopped working box from console, or subprocess hang with Idle. -- nosy: +ethan.furman versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14010 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Changes by Mark Lawrence breamore...@yahoo.co.uk: -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22916] Interpreter segfault on attempted tab complete
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - third party stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22916 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22918] Doc for __iter__ makes inexact comment about dict.__iter__
R. David Murray added the comment: They aren't equivalent in python2, either. I think probably the wording should be changed to something like and the method keys() should return an iterable that provides access to the same data. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22915] sax.parser cannot get xml data from a subprocess pipe
Jocelyn added the comment: Here is a patch to add a test to test_sax.py. I'm not sure on the fix. Is the following one a correct one ? def prepareParser(self, source): if source.getSystemId() is not None: -self._parser.SetBase(source.getSystemId()) +self._parser.SetBase(str(source.getSystemId())) Or should I remove the call to SetBase if getSystemId() is not a string ? -- keywords: +patch Added file: http://bugs.python.org/file37249/test-22915.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22915] sax.parser cannot get xml data from a subprocess pipe
Jocelyn added the comment: Forgot to attach the testcase when opening the bug. -- Added file: http://bugs.python.org/file37250/toto.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22917] Calculating problem
heme added the comment: Hi SilentGhost Thanx for a quick response. Sorry to hear that it is not a bug, my old GW basic interpretor from 1988 has no problem with this simple calculation (123.56 - 62.12 = 61.44) but my new Python interpreter cannot give me a correct answer. Yes, I know about precision, I have been using C for several years, but as I am interested in the Raspberry Pi I would like to use Python with it. And as I would use it as a data collector (from instruments), I need good precision and reliability. Is there anything I can do? (exept changing to another language) brg Henning SilentGhost skrev den 22/11/2014 21:33: SilentGhost added the comment: Hi Henning, this is not a bug. This is to do with how floating point numbers represented in computers. I'd suggest https://en.wikipedia.org/wiki/IEEE_floating_point [1] as a starting point. Briefly, due to binary base that the computers operate on, not every number can be stored/represented precisely. In any case there are plenty of other information online that you can find useful, the easiest solution is to output correctly formatted strings corresponding to your answers. Good luck. -- nosy: +SilentGhost resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22917 [2] ___ Links: -- [1] https://en.wikipedia.org/wiki/IEEE_floating_point [2] http://bugs.python.org/issue22917 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22917 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22917] Calculating problem
Mark Lawrence added the comment: https://docs.python.org/3/tutorial/floatingpoint.html -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22917 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Changes by Martin Dengler mar...@martindengler.com: -- nosy: +mdengler ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22919] Update PCBuild for VS 2015
Steve Dower added the comment: Fixed and pushed a minor issue with debug builds - I wasn't setting the 'g' suffix on the tcltk libs correctly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22919 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22917] Calculating problem
heme added the comment: Thank you I understand that it is not always that you see what you get (GW basic has shurely cut off the big precision, and Python doesnt, so I see the small difference. I will take care of thinking of it next time! Sorry for any inconvience. brg Henning Mark Lawrence skrev den 23/11/2014 00:23: Mark Lawrence added the comment: https://docs.python.org/3/tutorial/floatingpoint.html [1] -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22917 [2] ___ Links: -- [1] https://docs.python.org/3/tutorial/floatingpoint.html [2] http://bugs.python.org/issue22917 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22917 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22918] Doc for __iter__ makes inexact comment about dict.__iter__
Éric Araujo added the comment: The Python 2 doc is alright, the same line says that d.__iter__() is equivalent to d.iterkeys(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22921] SSLContext's check_hostname needlessly intertwined with SNI
New submission from Donald Stufft: The SSLContext().wrap_socket() method allows you to pass in a server_hostname option which will be used for two purposes, it will be used as the server name for SNI and it will be used to verify the server name of the certificate. However currently if the OpenSSL you're using does not have SNI then sending the server_hostname option to wrap_socket() will raise a ValueError. I think that instead server_hostname should always be accepted by SSLContext().wrap_socket() regardless of if SNI is available or if check_hostname is available. It's just going to be stored and used later so we can conditonally use it for SNI or for checking the hostname depending on if SNI is available or checking if a hostname is available. The way it works right now is that unless you're happy not working when SNI is not available you have to check the hostname yourself. If we can fix this, I think it would be smart to do it ASAP and get it into Python 2.7.9 and backported to the various Python 3.x's so that in the near future it works with all recent versions of the various Pythons (though older micro releases it may not). This shouldn't break any code since it's changing what used to be an error into a saner working case. -- messages: 231544 nosy: alex, benjamin.peterson, christian.heimes, dstufft priority: normal severity: normal status: open title: SSLContext's check_hostname needlessly intertwined with SNI type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22921 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22915] sax.parser cannot get xml data from a subprocess pipe
R. David Murray added the comment: Has anyone investigated what exactly sax uses SystemId/SetBase *for*? I think think we need that info in order to decide what to do, and I'm not familiar with sax. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
