Re: GUI toolkit(s) status
Am 21.11.14 05:49, schrieb Paul Rubin: Terry Reedy tjre...@udel.edu writes: Tcl/Tk currently use UCS-2, which only handles BMP chars. Alternatives to support astral chars: [other encodings] This is not entirely true: Tcl supports lazy typing, i.e. values (Tcl_Obj) are cast upon request into various Tcl_ObjTypes. For strings, a dialect of UTF8 and UCS-2 are suported, where UCS-2 is called Uncode-string and the UTF8-version just string. So in principle it would be feasible to implement something similar to the Python flexible strig representation. The problem is that this is only half of the story: * There is the regexp engine. Tcl uses Henry Spencer's engine (also used in MySQL), which is limited to UCS-2, but Spencer retired and nobody else understands the code. * For GUI, more support is needed e.g. to do LTR rendering. In principle, FriBiDi can do the work http://wiki.tcl.tk/40273 , but it is under GPL and therefore will never go into Tk * Tk is small compared to other toolkits, but still large enough that with less than half a developer currently working on it, and three supported platforms, it is unlikely to be fixed soon UTF-32 ... memory hit. However, most tk apps are not text heavy ... UFT-8: Makes indexing O(n). Given that most tk apps aren't text heavy, UTF-8 seems fine: when has the O(n) indexing been found to be a real problem in practice? These kind of questions are discussed in the TCT before decision which string rep should be the default one. The text widet has other issues, too, e.g. it is quite slow on long lines. There is a binding to Scintilla, which could come at rescue. Apple is a moving target, they pulled the rug from under Tk's feet twice over the past 10 years. Hmm interesting. Then there's also lots of new targets like mobile phones which Tk hasn't been ported to Afaik. Well, there is kind of a port to Android called androwish. http://www.ch-werner.de/sdltk/AndroWish/ It is based on SDL and displays the X version on Android. In principle it works, but never looks like a real Android app (though for games it's great). Would be interesting to see Tkinter running there, too. A possible solution for Tk is to replace the non-C Tcl parts of TK with Python (or the CPython API functions as needed for speed). I have no idea how horrendous a project creating Py/Tk would be. The Perl people tried this earlier, IIRC - the first bindings were not issuing Tcl commands, but calling Tk from C. It was later redesigned like Tkinter. Tcl itself is reasonably small and portable, the problem is the bindings (C code) to all the different window systems Tk supports. Tcl is not just an interpreter, but also a big C library for handling strings, File I/O over VFS, Threads etc. All of this code in Tk would need to be replaced. It would be an almost complete rewrite of the non-GUI parts of Tk. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
Chris Angelico ros...@gmail.com: Then you need to read more about Unicode. The *codepoint* for the letter 'A' is 65. That is not Unicode, that is one part of the Unicode spec. I don't think Python users need to know anything more about Unicode than they need to know about IEEE-754. How many bits are reserved for the mantissa? I don't remember and I don't see why I should care. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Fri, Nov 21, 2014 at 7:16 PM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: Then you need to read more about Unicode. The *codepoint* for the letter 'A' is 65. That is not Unicode, that is one part of the Unicode spec. I don't think Python users need to know anything more about Unicode than they need to know about IEEE-754. How many bits are reserved for the mantissa? I don't remember and I don't see why I should care. At what point can a Python float no longer represent every integer? That's why you should care. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Using Python for date calculations
I've finally found a use for Python. When, in the course of my genealogy research, I look at census or burial records, I often want to work out a person's date of birth from their age. It's a simple matter of mental arithmetic, but I sometimes get it wrong, and mislead myself. There are calculators and date calculation programs, but they are usually too complicated and try to do too much, so by the time you've worked out what to do it takes much longer. This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. It is sometimes better to have a simple program that does one thing well than a complex one that does lots of things, but none of them very efficiently. The average hand calculator can do the same job, but you have to pick it up and put it down, and you can't easily see if you've made a typo. Having said that, however, yes, I would perhaps like to use Python for more complicated date processing routines, namely to convert the kinds of dates produced by genealogy programs to a simple -mm-dd that computer database programs can understand, so that Abt May 1677 would be rendered as 1677-05-00 Has anyone done something like that in Python? -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes hayes...@telkomsa.net wrote: This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born One thing to be careful of: The input() function in Python 2 should be avoided. Instead, use int(raw_input(Year: )) and correspondingly Age. It's much safer and clearer than what you have, which is an alias for eval(raw_input(Year: )) - very dangerous. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On 11/21/2014 12:35 AM, Steve Hayes wrote: I've finally found a use for Python. When, in the course of my genealogy research, I look at census or burial records, I often want to work out a person's date of birth from their age. It's a simple matter of mental arithmetic, but I sometimes get it wrong, and mislead myself. There are calculators and date calculation programs, but they are usually too complicated and try to do too much, so by the time you've worked out what to do it takes much longer. This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. It is sometimes better to have a simple program that does one thing well than a complex one that does lots of things, but none of them very efficiently. The average hand calculator can do the same job, but you have to pick it up and put it down, and you can't easily see if you've made a typo. Having said that, however, yes, I would perhaps like to use Python for more complicated date processing routines, namely to convert the kinds of dates produced by genealogy programs to a simple -mm-dd that computer database programs can understand, so that Abt May 1677 would be rendered as 1677-05-00 Has anyone done something like that in Python? The datetime module has lots of capabilities including the several you mention. See https://docs.python.org/2/library/datetime.html Gary Herron -- https://mail.python.org/mailman/listinfo/python-list
Re: How to access Qt components loaded from file?
On Thu, 20 Nov 2014 22:41:02 +, Juan Christian wrote: On Thu Nov 20 2014 at 8:20:29 PM alister alister.nospam.w...@ntlworld.com wrote: Then either do the necessary work (you have just proven you can)or find a better way of communicating with this news group(NNTP or the mailing list), otherwise you may find a number of good people simply ignore your posts. While you are at it try to restrict your replies to text only, i see a lot of html garbage at the end of your posts which is also off putting. Which HTML garbage you talking about? All of this VVV div class=gmail_quoteOn Thu Nov 20 2014 at 8:20:29 PM alister lt;a href=mailto:alister.nospam.w...@ntlworld.com;alister.nospam.w...@ntlworld.com/ agt; wrote:blockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex Then either do the necessary work (you have just proven you can)or find abr better way of communicating with this news group(NNTP or the mailingbr list), otherwise you may find a number of good people simply ignore yourbr posts.br br While you are at it try to restrict your replies to text only, i see abr lot of html garbage at the end of your posts which is also off putting.br/blockquotedivbr/divdivWhich HTML garbage you talking about? /div/div -- Use the Force, Luke. -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico ros...@gmail.com wrote: On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes hayes...@telkomsa.net wrote: This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born One thing to be careful of: The input() function in Python 2 should be avoided. Instead, use int(raw_input(Year: )) and correspondingly Age. It's much safer and clearer than what you have, which is an alias for eval(raw_input(Year: )) - very dangerous. I though input() was OK for integers. -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, Nov 21, 2014 at 9:15 PM, Steve Hayes hayes...@telkomsa.net wrote: On Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico ros...@gmail.com wrote: On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes hayes...@telkomsa.net wrote: This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born One thing to be careful of: The input() function in Python 2 should be avoided. Instead, use int(raw_input(Year: )) and correspondingly Age. It's much safer and clearer than what you have, which is an alias for eval(raw_input(Year: )) - very dangerous. I though input() was OK for integers. In Py2, input() is basically not OK for anything. On the (extremely!) rare occasions when you actually want to eval() something the user types, it's better to be explicit: eval(raw_input()). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On 21/11/2014 08:50, Gary Herron wrote: On 11/21/2014 12:35 AM, Steve Hayes wrote: I've finally found a use for Python. When, in the course of my genealogy research, I look at census or burial records, I often want to work out a person's date of birth from their age. It's a simple matter of mental arithmetic, but I sometimes get it wrong, and mislead myself. There are calculators and date calculation programs, but they are usually too complicated and try to do too much, so by the time you've worked out what to do it takes much longer. This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. It is sometimes better to have a simple program that does one thing well than a complex one that does lots of things, but none of them very efficiently. The average hand calculator can do the same job, but you have to pick it up and put it down, and you can't easily see if you've made a typo. Having said that, however, yes, I would perhaps like to use Python for more complicated date processing routines, namely to convert the kinds of dates produced by genealogy programs to a simple -mm-dd that computer database programs can understand, so that Abt May 1677 would be rendered as 1677-05-00 Has anyone done something like that in Python? The datetime module has lots of capabilities including the several you mention. See https://docs.python.org/2/library/datetime.html Gary Herron As we're now firmly heading into the Python 3 era would people please be kind enough to use the Python 3 links. I know it's only a single character change but it's the principle to me. TIA. -- 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: How to fix those errors?
On 19/11/2014 1:40 PM, Chris Angelico wrote: On Wed, Nov 19, 2014 at 2:02 PM, alex23 wuwe...@gmail.com wrote: The first time I got a T_PAAMAYIM_NEKUDOTAYIM error, I just about flipped my desk in rage. If that were Hebrew for scope resolution operator, would it be less rage-inducing? Not especially. I prefer errors to actually use the syntax of the language where possible. -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, Nov 21, 2014 at 9:20 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: As we're now firmly heading into the Python 3 era would people please be kind enough to use the Python 3 links. I know it's only a single character change but it's the principle to me. TIA. The OP was clearly using Python 2 (as evidenced by the paren-less 'print'), so IMO a Py2 docs link is appropriate. But I would strongly suggest that the OP move to Py3. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On 2014-11-20 19:53, Rick Johnson 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. The reason Python finds the library module instead of my module is because the Python library is higher in search path than my module. What messed-up version of Python are you running? Or did you fail to test your conjecture? $ cat calendar.py print(This is my local calendar.py) x=1 $ cat importtest.py import calendar print(dir(calendar)) $ python2 importtest.py This is my local calendar.py ['__builtins__', '__doc__', '__file__', '__name__', '__package__', 'x'] $ python3 importtest.py This is my local calendar.py ['__builtins__', '__cached__', '__doc__', '__file__', '__name__', '__package__', 'x'] It finds my local module, not the system calendar module. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, 21 Nov 2014 12:15:03 +0200, Steve Hayes wrote: On Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico ros...@gmail.com wrote: On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes hayes...@telkomsa.net wrote: This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born One thing to be careful of: The input() function in Python 2 should be avoided. Instead, use int(raw_input(Year: )) and correspondingly Age. It's much safer and clearer than what you have, which is an alias for eval(raw_input(Year: )) - very dangerous. I though input() was OK for integers. the problem with input is code-injection which is very similar to sql injection (httpd://xkcd.com/327). the data entered by the user is processed as if it was python code, this means the user could enter a command (or sequence of commands) that cause serious problems to you computer including but not limited to:- Installing a virus Deleting all your data causing your central heating to explode (unlikely but if your central heating is on your network anything is possible) (I am beginning to think my fortune cookie signature generator is psychic) -- THIS time it really is fixed. I mean, how many times can we get it wrong? At some point, we just have to run out of really bad ideas.. - Linus Torvalds -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, 21 Nov 2014 10:20:06 +, Mark Lawrence wrote: On 21/11/2014 08:50, Gary Herron wrote: On 11/21/2014 12:35 AM, Steve Hayes wrote: I've finally found a use for Python. When, in the course of my genealogy research, I look at census or burial records, I often want to work out a person's date of birth from their age. It's a simple matter of mental arithmetic, but I sometimes get it wrong, and mislead myself. There are calculators and date calculation programs, but they are usually too complicated and try to do too much, so by the time you've worked out what to do it takes much longer. This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. It is sometimes better to have a simple program that does one thing well than a complex one that does lots of things, but none of them very efficiently. The average hand calculator can do the same job, but you have to pick it up and put it down, and you can't easily see if you've made a typo. Having said that, however, yes, I would perhaps like to use Python for more complicated date processing routines, namely to convert the kinds of dates produced by genealogy programs to a simple -mm-dd that computer database programs can understand, so that Abt May 1677 would be rendered as 1677-05-00 Has anyone done something like that in Python? The datetime module has lots of capabilities including the several you mention. See https://docs.python.org/2/library/datetime.html Gary Herron As we're now firmly heading into the Python 3 era would people please be kind enough to use the Python 3 links. I know it's only a single character change but it's the principle to me. TIA. I think this was because the OP is clearly using python 2 he may be better of moving to python 3 but providing links to documents of his current version is probably more helpful than providing python 3 links-in this case -- Martin was probably ripping them off. That's some family, isn't it? Incest, prostitution, fanaticism, software. -- Charles Willeford, Miami Blues -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, Nov 21, 2014 at 9:33 PM, alister alister.nospam.w...@ntlworld.com wrote: the data entered by the user is processed as if it was python code, this means the user could enter a command (or sequence of commands) that cause serious problems to you computer including but not limited to:- Installing a virus Deleting all your data causing your central heating to explode (unlikely but if your central heating is on your network anything is possible) That's the issue of malice. On a personal system, that's not really a question; there are plenty of programs I've written for my own use that have immense power. But there's also the risk of typos - one small error, and it's gone off doing crazy stuff. Now, maybe you want it to eval. There are times when I conceptually want enter an integer, but it makes good sense to be able to type 1+2 and have it act as if I typed 3. That's fine... but if you want eval, write eval into your code. Be explicit: eval(raw_input(Enter a number: )) makes it very clear that you're accepting code at the console. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python Logging and printf()
Hi Team , Iam using the python logging module to log the events for my application into a log file . I have set the logging level to DEBUG as shown below logging.basicConfig(filename=options.log_file, level=logging.DEBUG, format='%(asctime)s %(levelname)s:%(message)s', datefmt='%m/%d/%Y %I:%M:%S %p') iam also using logging.warning(),logging.error(),logging.info() etc as and when required. Please provide your input on the below questions. (1). How do i guarantee that all console messages will be logged into the logfile ? (2) I feel the need to retain few print(), how do I ensure the print() messages are also logged into the log file. Regards, Ganesh -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Logging and printf()
On 21 Nov 2014, at 11:48, Ganesh Pal wrote: Hi Team , Iam using the python logging module to log the events for my application into a log file . I have set the logging level to DEBUG as shown below logging.basicConfig(filename=options.log_file, level=logging.DEBUG, format='%(asctime)s %(levelname)s:%(message)s', datefmt='%m/%d/%Y %I:%M:%S %p') iam also using logging.warning(),logging.error(),logging.info() etc as and when required. Please provide your input on the below questions. (1). How do i guarantee that all console messages will be logged into the logfile ? There is no guarantee, it's a software. But all the log messages have to be stored in the logfile (2) I feel the need to retain few print(), how do I ensure the print() messages are also logged into the log file. the print function or print keyword don't use the logging module, you need to use it. Regards, Ganesh -- https://mail.python.org/mailman/listinfo/python-list -- Stéphane Wirtel - http://wirtel.be - @matrixise -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On 11/20/14 10:53 PM, Rick Johnson wrote: If you had taken the time to read my example utilizing a lobby boy, then you might have understood what i was talking about. Rick, if you are frustrated that people don't know what you are talking about, you should try writing shorter messages, with less bombast. I don't know if you are aiming for humor with your messages, but to my ears, you are verging on self-parody. I'm surprised that people are taking you seriously. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Logging and printf()
On Fri, Nov 21, 2014 at 9:48 PM, Ganesh Pal ganesh1...@gmail.com wrote: Please provide your input on the below questions. (1). How do i guarantee that all console messages will be logged into the logfile ? (2) I feel the need to retain few print(), how do I ensure the print() messages are also logged into the log file. If you're using Python 3, you can shadow print() with your own function. The logging functions don't have the same signature, so you'd need to write a wrapper (or else stick to a strict policy of one argument to print() and it must be a string), but it's certainly possible. But part of the point of the logging module is that it's not the same as console messages: you can reduce log spam by changing the logging level. So no, you don't have a guarantee that all console messages will be logged to the log file. If you want that, I would suggest a process-level wrapper - something which invokes a subprocess with redirected stdout and/or stderr - or, at very least, a startup routine that does the redirection (which will have similar effect, except that it can't catch startup failure messages from Python itself). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to access Qt components loaded from file?
On Fri Nov 21 2014 at 8:05:30 AM alister alister.nospam.w...@ntlworld.com wrote: All of this VVV [...] I'm sorry, I didn't know, but it seems there isn't any option to remove that in the Inbox (new Gmail), do you guys use any special program or client to use list? -- https://mail.python.org/mailman/listinfo/python-list
Re: How to access Qt components loaded from file?
On Fri, 21 Nov 2014 12:10:21 +, Juan Christian wrote: On Fri Nov 21 2014 at 8:05:30 AM alister alister.nospam.w...@ntlworld.com wrote: All of this VVV [...] I'm sorry, I didn't know, but it seems there isn't any option to remove that in the Inbox (new Gmail), do you guys use any special program or client to use list? div class=gmail_quoteOn Fri Nov 21 2014 at 8:05:30 AM alister lt;a href=mailto:alister.nospam.w...@ntlworld.com;alister.nospam.w...@ntlworld.com/ agt; wrote:brblockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1exAll of this VVVbr[...]/blockquotedivbr/divdivI#39;m sorry, I didn#39;t know, but it seems there isn#39;t any option to remove that in the Inbox (new Gmail), do you guys use any special program or client to use list? /div/div personally I access the news group via a news server using pan others use the mailing list via their normal email client -- ... Had this been an actual emergency, we would have fled in terror, and you would not have been informed. -- https://mail.python.org/mailman/listinfo/python-list
Request for assistance
I am in the process of creation of synthesis site looking at other sites, do any of you can aide true value of some books for aggregate roads, aggregate sites, and thank you -- https://mail.python.org/mailman/listinfo/python-list
Re: How to access Qt components loaded from file?
I am in the process of creation of synthesis site looking at other sites, do any of you can aide true value of some books for aggregate roads, aggregate sites, and thank you -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, Nov 21, 2014, at 05:33, alister wrote: the problem with input is code-injection which is very similar to sql injection (httpd://xkcd.com/327). the data entered by the user is processed as if it was python code, this means the user could enter a command (or sequence of commands) that cause serious problems to you computer including but not limited to:- Except standard input for interactive programs is rarely across a privilege boundary. The user can accomplish any of these far more easily by entering a command into their shell. (Well, more easily depending on which is better able to use the API for their central heating, but the others certainly). There are good reasons to avoid it (user is likely to be surprised by weird error messages, causing a crash due to a typo), but this kind of paranoia is the same as has people in some circles refusing to use strlcpy or fgets because they can cause silent truncation. -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, Nov 21, 2014, at 05:47, Chris Angelico wrote: Now, maybe you want it to eval. There are times when I conceptually want enter an integer, but it makes good sense to be able to type 1+2 and have it act as if I typed 3. That's fine... but if you want eval, write eval into your code. Be explicit: eval(raw_input(Enter a number: )) makes it very clear that you're accepting code at the console. Out of curiosity, is there a way to use eval safely (i.e. strictly limiting what it has access to) across a privilege boundary? This also comes up for pickle and other serialization formats that can store arbitrary classes (i.e. call arbitrary constructors). I remember an IRC channel I sometimes go in has a chatbot (written in perl) which has a calculator function, it goes with the low-tech solution of removing via regex anything that isn't an operator or a number literal. -- https://mail.python.org/mailman/listinfo/python-list
Re: *.sdf database access
On Saturday, April 21, 2012 6:55:55 AM UTC-4, Alex Willmer wrote: On Apr 19, 9:18 pm, Page3D pag...@gmail.com wrote: Hi, I am trying to connect and access data in a *.sdf file on Win7 system using Python 2.7. I have three questions: 1. What python module should I use? I have looked at sqlite3 and pyodbc. However, I can seem to get the connection to the database file setup properly. I assume you mean SQL Server Compact by *.sdf. However please note that there are several several file formats matching SDF http://en.wikipedia.org/wiki/SDF#Computing and explicit is better than implicit. The sqlite3 module won't help - that's for sqlite files, which an entirely different file format. Wikpedia says of SQL Server Compact An ODBC driver for SQL CE does not exist, and one is not planned either. Native applications may use SQL CE via OLE DB http://en.wikipedia.org/wiki/SQL_Server_Compact. I believe the adodbapi module, part of PyWin32 http://sourceforge.net/projects/pywin32/files/ can connect over OLE DB. 2. How can I determine the appropriate connection string? I have opened database file in Visual Studio and can see the tables. I don't understand where to find the connection string in Visual Studio. These look promising http://www.connectionstrings.com/sql-server-2005-ce 3. Assuming a module from (1) above, does anyone have a code snippet for connecting to the database and then accessing a varbinary (image) in one of the tables of the databese? Pass, I'm afraid Regards, Alex Thank you for the pywin32 link, I assume the problem/issue must have been resolved as there were not posts further. I could successfully ping to the database and get the desired results, let me know if anybody still needs the connection code. -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Sat, Nov 22, 2014 at 12:58 AM, random...@fastmail.us wrote: On Fri, Nov 21, 2014, at 05:47, Chris Angelico wrote: Now, maybe you want it to eval. There are times when I conceptually want enter an integer, but it makes good sense to be able to type 1+2 and have it act as if I typed 3. That's fine... but if you want eval, write eval into your code. Be explicit: eval(raw_input(Enter a number: )) makes it very clear that you're accepting code at the console. Out of curiosity, is there a way to use eval safely (i.e. strictly limiting what it has access to) across a privilege boundary? This also comes up for pickle and other serialization formats that can store arbitrary classes (i.e. call arbitrary constructors). No, there is not. Not in Python. You can sandbox the entire process, but you can't eval less-privileged code in a more-privileged process, ever. I remember an IRC channel I sometimes go in has a chatbot (written in perl) which has a calculator function, it goes with the low-tech solution of removing via regex anything that isn't an operator or a number literal. Would ast.literal_eval work? If not, it would at least be possible to do an AST parse, then walk the tree and see if there's anything that isn't an acceptable node type. There'd have to be draconian rules (no attribute access, for instance), but it could be done more intelligently than regex. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI toolkit(s) status
On 11/20/14, 4:04 AM, Christian Gollwitzer wrote: Apple is a moving target, they pulled the rug from under Tk's feet twice over the past 10 years. Nobody knows if Tk will continue to exist on the mac if Cocoa is withdrawn some day and replaced by a new and completely different windowing framework. There is indeed a lack of manpower and expertise for Tk/Mac: I'm pretty much it, except when someone submits a patch to scratch a specific itch. Apple has introduced Swift as a new systems language, but (as I understand it) the intent is to supersede Objective-C as a language, not the Cocoa frameworks per se. So I think the risk of a brand-new windowing system replacing Cocoa (and thus requiring yet another new implementation of Tk) is pretty small. There may be a larger risk with newer API's being expressed mainly in Swift, which would require conversion to Objective-C for legacy codebases, but that is a smaller hurdle to clear. --Kevin -- 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: GUI toolkit(s) status
On 11/20/14, 11:34 PM, Terry Reedy wrote: A possible solution for Tk is to replace the non-C Tcl parts of TK with Python (or the CPython API functions as needed for speed). I have no idea how horrendous a project creating Py/Tk would be. It would be very horrendous. See Perl/Tk as the example. They ripped out the Tcl interpreter and interfaced directly with Tk's C API. The result was a rigid, inflexible binding that was never ported to the Mac (because it required a C implementation) and could never be easily updated to take advantage of new features in Tk, because again it required a C implementation. Perl-Tk still exists, but more modern bindings like ActiveState's Tkx module have restored the Tcl interpreter, giving you access to all Tk advances and platforms for free. Apart from the ease of updating Tk features, from a design standpoint I think this is the right call. There may be a little extra overhead in having an extra interpreter embedded, but that is what Tcl was originally designed for: embedding. It handles this requirement more easily and with less pain than most languages. I think that's why Tk became the default GUI binding of choice for other scripting languages. --Kevin -- 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: Using Python for date calculations
On Fri, 21 Nov 2014 08:54:23 -0500, random832 wrote: On Fri, Nov 21, 2014, at 05:33, alister wrote: the problem with input is code-injection which is very similar to sql injection (httpd://xkcd.com/327). the data entered by the user is processed as if it was python code, this means the user could enter a command (or sequence of commands) that cause serious problems to you computer including but not limited to:- Except standard input for interactive programs is rarely across a privilege boundary. The user can accomplish any of these far more easily by entering a command into their shell. (Well, more easily depending on which is better able to use the API for their central heating, but the others certainly). There are good reasons to avoid it (user is likely to be surprised by weird error messages, causing a crash due to a typo), but this kind of paranoia is the same as has people in some circles refusing to use strlcpy or fgets because they can cause silent truncation. If the program in question is purely for personal use then indeed it is not important, as you say I can just as easily stuff my computer without needing to play silly b**s with a python script. It is if the program is ever going to be used by others (or possibly worse running on something like a web server exposed to the public internet) that needs paranoia. my own personal opinion is that it is best to get into good habits even with personal use Quick Dirty scripts, you never know how they could evolve -- What terrible way to die. There are no good ways. -- Sulu and Kirk, That Which Survives, stardate unknown -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
random...@fastmail.us wrote:
Out of curiosity, is there a way to use eval safely (i.e. strictly
limiting what it has access to) across a privilege boundary? This also
comes up for pickle and other serialization formats that can store
arbitrary classes (i.e. call arbitrary constructors).
Not really. If there is, it is very hard.
Ned has a good write-up here:
http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html
Some years ago, Tav made an attempt to secure the interpreter against file
system writes:
http://tav.espians.com/a-challenge-to-break-python-security.html
That didn't work so well, although Tav's efforts towards building a
Capabilities version of Python are promising:
http://tav.espians.com/paving-the-way-to-securing-the-python-interpreter.html
Without a full parser, it's hard to defend against Denial Of Service attacks
like this:
# don't try this at home
eval(100**100**100)
We can *mitigate* the danger in a number of ways:
- Combination of blacklists and whitelists.
- Avoid *easy* access to built-ins by specifying the namespace that the code
should be executed in:
eval(code goes here, {'__builtins__'={}})
- If you need access to specific built-ins, add them to your namespace:
eval(code goes here, {'__builtins__'={}, 'int'=int})
- Disallow any expression which includes underscore _ characters, this will
make it harder (but maybe not impossible?) for an attacker to break out of
your sandbox.
- Have a short limit on the length of the expression. The shorter the
expression, the less surface an attacker has to attack. (An attacker may
find some clever trick to escape the sandbox, but it's harder to do so in
20 characters than in 200.)
- Run untrusted code in a separate process, with a timeout.
- Use your OS facilities to run that process in a chroot jail.
But even better is to avoid eval completely. If all you want is to evaluate
a few simple constant expressions:
py from ast import literal_eval
py literal_eval('[None, 23, hello, {0.5: x}]')
[None, 23, 'hello', {0.5: 'x'}]
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
Chris Angelico wrote:
On Fri, Nov 21, 2014 at 11:32 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
(E.g. there are millions of existing files across the world containing
text which use legacy encodings that are not compatible with Unicode.)
Not compatible with Unicode? There aren't many character sets out
there that include characters not in Unicode - that was the whole
point. Of course, there are plenty of files in unspecified eight-bit
encodings, so you may have a problem with reliable decoding - but if
you know what the encoding is, you ought to be able to represent each
character in Unicode.
What I meant was that some encodings -- namely ASCII and Latin-1 -- the
ordinals are exactly equivalent to Unicode, that is:
# Python 3
for i in range(128):
assert chr(i).encode('ASCII') == bytes([i])
for i in range(256):
assert chr(i).encode('Latin-1') == bytes([i])
That's not quite as significant as I thought, though. What is significant is
that a pure ASCII file on disk can be read by a program assuming UTF-8:
for i in range(128):
assert chr(i).encode('UTF-8') == bytes([i])
although the same is not the case for Latin-1 encoded files.
Not compatible with any of the UTFs, that's different. Plenty of that
in the world.
You are certainly correct that in it's full generality, text is much
more than just a string of code points. Unicode strings is a primitive
data type. A powerful and sophisticated text processing application may
even find Python strings too primitive, possibly needing something like
ropes of graphemes rather than strings of code points.
That's probably more an efficiency point, though. It should be
possible to do a perfect two-way translation between your grapheme
rope and a Python string; otherwise, you'll have great difficulty
saving your file to the disk (which will normally involve representing
the text in Unicode, then encoding that to bytes).
Well, yes. My point, agreeing with Marko, is that any time you want to do
something even vaguely related to human-readable text, code points are
not enough. For example, if I give a string containing the following two
code points in this order:
LATIN SMALL LETTER E
COMBINING CIRCUMFLEX ACCENT
then my application should treat that as a single character and display it
as:
LATIN SMALL LETTER E WITH CIRCUMFLEX
which looks like this: ê
rather than two distinct characters eˆ
Now, that specific example is a no-brainer, because the Unicode
normalization routines will handle the conversion. But not every
combination of accented characters has a canonical combined form. What
about something like this?
'w\N{COMBINING CIRCUMFLEX ACCENT}\N{COMBINING OGONEK}\N{COMBINING CARON}'
If I insert a character into my string, I want to be able to insert before
the w or after the caron, but not in the middle of those three code points.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On 11/21/14 9:55 AM, Steven D'Aprano wrote: - Use your OS facilities to run that process in a chroot jail. If you are interested, this is the facility that edX uses to run untrusted Python code on the servers: https://github.com/edx/codejail -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
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. The Python import system gives you the ability to create packages, so use them -- create a package to contain all the widgets you create. If they're only for your own use, then you can just call it ricklib or anything else you want. Then your import becomes: import ricklib.calendar # or from ricklib import calendar Now you can drop as much stuff in there as you like, and none of it will ever conflict with the standard library (unless a standard ricklib module is added, which is unlikely). The reason Python finds the library module instead of my module is because the Python library is higher in search path than my module. Your PYTHONPATH is added to the sys.path before the Python library, not after, so to the extent that there is an issue, it's actually the other way around. You would get your local calendar module when trying to import the system calendar module. # Contrary to popular belief, sys.path is *NOT* a module, # # no, it's a global! # I really doubt that this is a popular belief. 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. And after all that, it would still fail if you happened to want to import both calendar modules into the same module. in the 25% of cases where *NAME SHADOWING* or where the author knows the location and can specify the location to save lobby boy from knocking on doors until his knuckles bleed, the author should have an option defining the search path *LOCALLY* (in a manner that will *NOT* affect the import search path further down the import chain), WITHOUT needing to import one of the many discombobulated and confusing import tools that Python has tortured this community with. By doing so, the author would also make the module non-portable. This is a major problem if they intend to distribute it, but still a problem even if they don't. Any time the code is moved to a new system and placed in a new location (or worse: moved to a new operating system) the code will have to be updated. And you can pretty much forget about hosting it on a network share. 3) Filepath imports (deprecated in 3.4 but under discussion for reprecation or replacement) import importlib.machinery loader = importlib.machinery.SourceFileLoader(module.name, /path /to/file.py) foo = loader.load_module() foo.MyClass() That's ridiculously noisy. I have an idea, if you *REALLY* want to introduce boilerplate hell then Python should adopt import header files, NOT! It's three lines of code to replace one. Two if you exclude the importlib.machinery import that doesn't need to be repeated. Is this really any worse than something like: local_search_path.insert(0, /path/to/local/module) import my_local_module that you are proposing? -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sat, Nov 22, 2014 at 2:23 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Chris Angelico wrote:
On Fri, Nov 21, 2014 at 11:32 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
(E.g. there are millions of existing files across the world containing
text which use legacy encodings that are not compatible with Unicode.)
Not compatible with Unicode? There aren't many character sets out
there that include characters not in Unicode - that was the whole
point. Of course, there are plenty of files in unspecified eight-bit
encodings, so you may have a problem with reliable decoding - but if
you know what the encoding is, you ought to be able to represent each
character in Unicode.
What I meant was that some encodings -- namely ASCII and Latin-1 -- the
ordinals are exactly equivalent to Unicode, that is:
That's not quite as significant as I thought, though. What is significant is
that a pure ASCII file on disk can be read by a program assuming UTF-8:
although the same is not the case for Latin-1 encoded files.
Yep. Thing is, Unicode can't magically convert all files on all
disks... but with a good codec library, you can at least convert
things as you find them. (I was reading MacRoman files earlier this
year. THAT is an encoding I didn't expect I'd find in 2014.)
Well, yes. My point, agreeing with Marko, is that any time you want to do
something even vaguely related to human-readable text, code points are
not enough. ... What about something like this?
'w\N{COMBINING CIRCUMFLEX ACCENT}\N{COMBINING OGONEK}\N{COMBINING CARON}'
If I insert a character into my string, I want to be able to insert before
the w or after the caron, but not in the middle of those three code points.
Yes, which is a concern. Also a concern is the ability to detect other
boundaries, like words. None of these can be easily solved; all of
them can be dealt with by using the Unicode character data, which is
better than you get for most legacy encodings. In terms of Python
strings, it still makes sense to insert characters between those
combining characters; so what you're saying is that a text editor
widget needs to be aware of more than just code points. Which is
trivially obvious in the presence of RTL text, too; cursor positions
through differing-direction text will be an issue.
The problems you're citing aren't Unicode problems. They stem from the
complexities of human languages. Unicode just makes them a bit more
visible to English-only-speaking programmers.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to access Qt components loaded from file?
On 21/11/2014 12:10, Juan Christian wrote: On Fri Nov 21 2014 at 8:05:30 AM alister alister.nospam.w...@ntlworld.com mailto:alister.nospam.w...@ntlworld.com wrote: All of this VVV [...] I'm sorry, I didn't know, but it seems there isn't any option to remove that in the Inbox (new Gmail), do you guys use any special program or client to use list? Thunderbird on Windows where I can easily access over 300 Python mailing lists plus a number of blogs, recipes from Activestate and other bits all via gmane or gmene. -- 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: Using Python for date calculations
On Fri, 21 Nov 2014 10:20:06 +, Mark Lawrence breamore...@yahoo.co.uk wrote: On 21/11/2014 08:50, Gary Herron wrote: On 11/21/2014 12:35 AM, Steve Hayes wrote: I've finally found a use for Python. When, in the course of my genealogy research, I look at census or burial records, I often want to work out a person's date of birth from their age. It's a simple matter of mental arithmetic, but I sometimes get it wrong, and mislead myself. There are calculators and date calculation programs, but they are usually too complicated and try to do too much, so by the time you've worked out what to do it takes much longer. This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. It is sometimes better to have a simple program that does one thing well than a complex one that does lots of things, but none of them very efficiently. The average hand calculator can do the same job, but you have to pick it up and put it down, and you can't easily see if you've made a typo. Having said that, however, yes, I would perhaps like to use Python for more complicated date processing routines, namely to convert the kinds of dates produced by genealogy programs to a simple -mm-dd that computer database programs can understand, so that Abt May 1677 would be rendered as 1677-05-00 Has anyone done something like that in Python? The datetime module has lots of capabilities including the several you mention. See https://docs.python.org/2/library/datetime.html Gary Herron As we're now firmly heading into the Python 3 era would people please be kind enough to use the Python 3 links. I know it's only a single character change but it's the principle to me. TIA. As I'm using Python 2 and I asked the question, I'm grateful that the answer was given in my dialect. -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Friday, November 21, 2014 4:29:48 AM UTC-6, Tim Chase wrote: What messed-up version of Python are you running? Or did you fail to test your conjecture? $ cat calendar.py print(This is my local calendar.py) x=1 $ cat importtest.py import calendar print(dir(calendar)) $ python2 importtest.py This is my local calendar.py ['__builtins__', '__doc__', '__file__', '__name__', '__package__', 'x'] $ python3 importtest.py This is my local calendar.py ['__builtins__', '__cached__', '__doc__', '__file__', '__name__', '__package__', 'x'] It finds my local module, not the system calendar module. You failed to provide the needed information! 1. We need to see the values in sys.path. So print them directly before making the call to import. 2. Where did you store your custom calendar.py script? Remember, import is an implicit mechanism, it works by searching the values of 'sys.path' one-by-one (if the module was not already loaded!) until the *FIRST* module matching the name you requested is found. If the folder that holds *your* custom calendar.py script is listed *before* the folder containing the python calendar modules then of course your module will be correctly loaded. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On 2014-11-22 02:23, Steven D'Aprano wrote:
LATIN SMALL LETTER E
COMBINING CIRCUMFLEX ACCENT
then my application should treat that as a single character and
display it as:
LATIN SMALL LETTER E WITH CIRCUMFLEX
which looks like this: ê
rather than two distinct characters eˆ
Now, that specific example is a no-brainer, because the Unicode
normalization routines will handle the conversion. But not every
combination of accented characters has a canonical combined form.
What about something like this?
'w\N{COMBINING CIRCUMFLEX ACCENT}\N{COMBINING OGONEK}\N{COMBINING
CARON}'
If I insert a character into my string, I want to be able to insert
before the w or after the caron, but not in the middle of those
three code points.
Things get even weirder if you have
'\N{LATIN SMALL LETTER E WITH CIRCUMFLEX}\N{COMBINING
OGONEK}\N{COMBINING CARON}'
and when you try to do comparisons like
s1 = '\N{LATIN SMALL LETTER E WITH CIRCUMFLEX}\N{COMBINING OGONEK}'
s2 = 'e\N{COMBINING CIRCUMFLEX ACCENT}\N{COMBINING OGONEK}'
s3 = 'e\N{COMBINING OGONEK}\N{COMBINING CIRCUMFLEX ACCENT}'
print(s1 == s2)
print(s1 == s3)
print(s2 == s3)
Then you also have the case where you want to edit text and the user
wants to remove the COMBINING OGONEK from the character, so you *do*
want to do something akin to
s4 = ''.join(c for c in s3 if c != '\N{COMBINING OGONEK}')
And yet, weird things happen if you try to remove the circumflex:
for test in (s1, s2, s3):
print(test == ''.join(
c for c in test if c != '\N{COMBINING CIRCUMFLEX ACCENT}'
)
They all make sense if you understand what's going on under the hood,
but from a visual/conceptual perspective, something feels amiss.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On 21/11/2014 15:50, Steve Hayes wrote: On Fri, 21 Nov 2014 10:20:06 +, Mark Lawrence breamore...@yahoo.co.uk As I'm using Python 2 and I asked the question, I'm grateful that the answer was given in my dialect. Luddite :) -- 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 Friday, November 21, 2014 12:06:54 PM UTC+5:30, Marko Rauhamaa wrote: Chris Angelico : On Fri, Nov 21, 2014 at 5:56 AM, Marko Rauhamaa wrote: I don't really like it how Unicode is equated with text, or even character strings. [...] Do you have actual text that you're unable to represent in Unicode? Not my point at all. I'm saying equating an abstract data type (string) with its representation (Unicode vector) is bad taste. We don't call numbers IEEE, Exactly. Do you genuinely have text that you can't represent in Unicode, or are you just arguing against Unicode to try to justify Python strings are something else as a basis for your code? Nobody is arguing against Unicode. I'm saying, let's talk about the forest instead of the trees (except when the trees really are the focus). Ive always felt the makers of C showed remarkably good taste in the names 'int' and 'float'. Unlike: Pascal: Int and Real PL/1: Fixed and Float IOW the more leaky abstraction used for real numbers is explicitly reminded. Likewise in 2014, and given the arguments, inconsistencies, etc remembering the nuts-n-bolts below the strings-represented-as-unicode abstraction may be in order. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On 11/20/2014 04:15 PM, Chris Angelico wrote:
On Fri, Nov 21, 2014 at 1:14 AM, Francis Moreau francis.m...@gmail.com
wrote:
Hi,
Thanks for the from __future__ import unicode_literals trick, it makes
that switch much less intrusive.
However it seems that I will suddenly be trapped by all modules which
are not prepared to handle unicode. For example:
from __future__ import unicode_literals
import locale
locale.setlocale(locale.LC_ALL, 'fr_FR')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib64/python2.7/locale.py, line 546, in setlocale
locale = normalize(_build_localename(locale))
File /usr/lib64/python2.7/locale.py, line 453, in _build_localename
language, encoding = localetuple
ValueError: too many values to unpack
Is the locale module an exception and in that case I'll fix it by doing:
locale.setlocale(locale.LC_ALL, b'fr_FR')
or is a (big) part of the modules in python 2.7 still not ready for
unicode and in that case I have to decide which prefix (u or b) I should
manually add ?
Sadly, there are quite a lot of parts of Python 2 that simply don't
handle Unicode strings. But you can probably keep all of those down to
just a handful of explicit bwhatever strings; most places should
accept unicode as well as str. What you're seeing here is a prime
example of one of this author's points (caution, long post):
http://unspecified.wordpress.com/2012/04/19/the-importance-of-language-level-abstract-unicode-strings/
The lesson of Python 3 is: give programmers a Unicode string type,
*make it the default*, and encoding issues will /mostly/ go away.
There's a whole ecosystem to Python 2 - some in the standard library,
heaps more in the rest of the world - and a lot of it was written on
the assumption that a byte is a character is an octet. When you pass
Unicode strings to functions written to expect byte strings, sometimes
you win, and sometimes you lose... even with the standard library
itself. But the Python 3 ecosystem has been written on the assumption
that strings are Unicode. It's only a narrow set of programs
(boundary code, where you're moving text across networks and stuff
like that) where the Python 2 model is easier to work with; and the
recent Py3 releases have been progressively working to relieve that
pain.
The absolute worst case is a function which exists in Python 2 and 3,
and requires a byte string in Py2 and a text string in Py3. Sadly,
that may be exactly what locale.setlocale() is. For that, I would
suggest explicitly passing stuff through str():
locale.setlocale(locale.LC_ALL, str('fr_FR'))
In Python 3, 'fr_FR' is already a str, so passing it through str()
will have no significant effect. (Though it would be worth commenting
that, to make it clear to a subsequent reader that this is Py2 compat
code.) In Python 2 with unicode_literals active, 'fr_FR' is a unicode,
so passing it through str() will encode it to ASCII, producing a byte
string that setlocale should be happy with.
By the way, the reason for the strange error message is clearer in
Python 3, which chains in another exception:
locale.setlocale(locale.LC_ALL, b'fr_FR')
Traceback (most recent call last):
File /usr/local/lib/python3.5/locale.py, line 498, in _build_localename
language, encoding = localetuple
ValueError: too many values to unpack (expected 2)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib/python3.5/locale.py, line 594, in setlocale
locale = normalize(_build_localename(locale))
File /usr/local/lib/python3.5/locale.py, line 507, in _build_localename
raise TypeError('Locale must be None, a string, or an iterable of
two strings -- language code, encoding.')
TypeError: Locale must be None, a string, or an iterable of two
strings -- language code, encoding.
So when it gets the wrong type of string, it attempts to unpack it as
an iterable; it yields five values (the five bytes or characters,
depending on which way it's the wrong type of string), but it's
expecting two. Fortunately, str() will deal with this. But make sure
you don't have the b prefix, or str() in Py3 will give you quite a
different result!
Yes I finally used str() since only setlocale() reported to have some
issues with unicode_literals active in my appliction.
Thanks Chris for your useful insight.
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sat, Nov 22, 2014 at 3:11 AM, Francis Moreau francis.m...@gmail.com wrote: Yes I finally used str() since only setlocale() reported to have some issues with unicode_literals active in my appliction. Thanks Chris for your useful insight. My pleasure. Unicode is a bit of a hobby-horse of mine, so I'm always happy to see people getting things right :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On 2014-11-21 07:52, Rick Johnson wrote: On Friday, November 21, 2014 4:29:48 AM UTC-6, Tim Chase wrote: What messed-up version of Python are you running? Or did you fail to test your conjecture? $ cat calendar.py print(This is my local calendar.py) x=1 $ cat importtest.py import calendar print(dir(calendar)) $ python2 importtest.py This is my local calendar.py ['__builtins__', '__doc__', '__file__', '__name__', '__package__', 'x'] $ python3 importtest.py This is my local calendar.py ['__builtins__', '__cached__', '__doc__', '__file__', '__name__', '__package__', 'x'] It finds my local module, not the system calendar module. You failed to provide the needed information! 1. We need to see the values in sys.path. So print them directly before making the call to import. 2. Where did you store your custom calendar.py script? Had you paid attention, having watched the creation of the two files and the invocation of stock python, you would know that they were in the same folder, and there's no modification of sys.path in the process. So if you're seeing different behaviors due to a modified sys.path, then you should be aware that *you* modified sys.path and thus broke things. The above was tested on Python2 and Python3, both on Linux (Debian in this case) and Win32 (using copy con instead of cat ) with the out-of-box install. The only time I've been stung by name overloading is in the indirect case of creating a local email.py file and then importing smtplib only to have things break in unforeseen ways. If smtplib used relative imports for $STDLIB/email.py I suspect it would ameliorate that particular issue for me. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python docs disappointing
On 2014-11-20, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: jstnms...@gmail.com wrote: I write this to address the criticism which targets a user's lack of responsibility for the real/implied/insinuated failings of the docs. As a relatively inexperienced student of programming, [...] After all, I'm a lot smarter than you, and I have thankfully learned make out a fool however obscurely he covers himself. I take my hat off to you, sir or madam, that is a brilliant satire of pretentious self-important impenetrable prose complaining about the lack of readability of another text. Were it written in green ink, it would have been perfect. ;) -- Grant Edwards grant.b.edwardsYow! I am having FUN... at I wonder if it's NET FUN or gmail.comGROSS FUN? -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
Rustom Mody rustompm...@gmail.com: Likewise in 2014, and given the arguments, inconsistencies, etc remembering the nuts-n-bolts below the strings-represented-as-unicode abstraction may be in order. No need to hide Unicode, but talking about a Unicode string is like talking about an electronic computer visible spectrum display mouse user interface ethernet socket magnetic file electric power supply The language spec calls the things just strings, as it should. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
On Sat, Nov 22, 2014 at 3:36 AM, Marko Rauhamaa ma...@pacujo.net wrote: No need to hide Unicode, but talking about a Unicode string is like talking about an electronic computer visible spectrum display mouse user interface ethernet socket magnetic file electric power supply The language spec calls the things just strings, as it should. I'm not sure what you mean here, because the adjectives all cut out other common constructs - a byte string, an analog computer, an IR or UV display, a blind-compatible UI, a Unix domain socket, an in-memory file, and a diesel power supply. Okay, I'm pushing it with the last one (they're usually called gen sets, not power supplies), and I don't often hear people talk about magnetic files, but the rest are definitely valid comparison/contrast terms. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Most gratuitous comments
On 2014-11-21, Marko Rauhamaa ma...@pacujo.net wrote: sohcahto...@gmail.com: My point was that I was making fun of CS professors that demand a comment on every line of code, regardless of how clear the line of code is. Unfortunately, a lot of software houses do a similar thing. Not quite every line, but stuff like: def write_line_to_file(file, line): Write a line to a file. file is the file to add a line to line is the line to add to the file ... And then they run the whole steaming pile through doxygen to generate several shelf-feet of utterly useless documentation to which than can proudly point the next time the ISO-900whatever inspectors come around. A few years later, the previously correct-but-pointless comments and wheelbarrows full of paper are now incorrect, and instead of providing zero value they provide _negative_ value. -- Grant Edwards grant.b.edwardsYow! ... I'm IMAGINING a at sensuous GIRAFFE, CAVORTING gmail.comin the BACK ROOM of a KOSHER DELI -- -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On 21/11/14 08:35, Steve Hayes wrote: I've finally found a use for Python. When, in the course of my genealogy research, I look at census or burial records, I often want to work out a person's date of birth from their age. It's a simple matter of mental arithmetic, but I sometimes get it wrong, and mislead myself. There are calculators and date calculation programs, but they are usually too complicated and try to do too much, so by the time you've worked out what to do it takes much longer. This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. [snip] This is keeping it too simple. Someone aged 50 (i.e. over 50 but not yet 51) today - 21st Nov 2014 - might have been born in 1963 or 1964 depending on their birthday. For me your calculation would return the correct answer (born in March), for my sister it would be wrong (born in December). Duncan -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Thu, Nov 20, 2014 at 10:54 PM, Gill Shen gillar...@gmail.com wrote: How is this behavior implemented under the hood? And why is this allowed at all? Is it just a curiosity or can you do something useful with it? Reference cycles are common in Python and other OO languages. For example, adding a widget to a window; the window contains references to its child widgets, and it's probably useful for the widgets to know what their parents are, so they would hold references back. A list containing itself is similarly a reference cycle. I don't know off-hand of any use for this specific case, but it's just a slightly tighter cycle than normal. -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Fri, Nov 21, 2014, at 02:00, Marko Rauhamaa wrote: Gill Shen gillar...@gmail.com: How is this [nesting] behavior implemented under the hood? Pointers. And why is this allowed at all? There's no reason not to. There's no reason not to allow it with tuples, but you can't do it. Mainly because doing it in a single literal would require special syntax, whereas you can simply append to a list a reference to itself. 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Fri, Nov 21, 2014 at 9:12 AM, Tim Chase python.l...@tim.thechases.com wrote: The only time I've been stung by name overloading is in the indirect case of creating a local email.py file and then importing smtplib only to have things break in unforeseen ways. If smtplib used relative imports for $STDLIB/email.py I suspect it would ameliorate that particular issue for me. Relative imports are based on package namespaces and can only be done within a package. There's no way to do a relative import from a separate top-level package, whether they happen to be found in the same directory or not. $ mkdir p1 $ touch p1/__init__.py $ echo 'from ..p2 import m2' p1/m1.py $ mkdir p2 $ touch p2/__init__.py $ touch p2/m2.py $ python3 -c 'import p1.m1' Traceback (most recent call last): File string, line 1, in module File /home/ikelly/p1/m1.py, line 1, in module from ..p2 import m2 ValueError: attempted relative import beyond top-level package -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Sat, Nov 22, 2014 at 4:39 AM, random...@fastmail.us wrote: There's no reason not to allow it with tuples, but you can't do it. Mainly because doing it in a single literal would require special syntax, whereas you can simply append to a list a reference to itself. 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. You can do it in C, I believe - PyTuple_New() followed by PyTuple_SetItem(x, 0, x) should do it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Fri, Nov 21, 2014, at 12:47, Chris Angelico wrote: You can do it in C, I believe - PyTuple_New() followed by PyTuple_SetItem(x, 0, x) should do it. Yeah, that's how I did it. I think python 2 crashed and python 3 didn't... or maybe it was the interactive interpreter that crashed and calling repr didn't, within the same version - I don't remember that well. -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Friday, November 21, 2014 9:34:55 AM UTC-6, Ian wrote: On Thu, Nov 20, 2014 at 8:53 PM, Rick Johnson 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. Are you also going to call drivers fools because they bought a certain brand of car only to have the airbag explode in their face? What's next, are you going to blame them for not wearing a mask? Why am *i* the fool when it's obvious that the creators of Python were either shortsighted and/or careless with the designs? The only people who suffer are those who put their trust in the designer, and not the designer himself -- something is wrong with this picture! The Python import system gives you the ability to create packages, so use them -- create a package to contain all the widgets you create. If they're only for your own use, then you can just call it ricklib or anything else you want. Of course, I did that a long time ago! But like everything in Python, when your try to be cleaver and create a workaround for the design flaws of this language (and there are many!) you end up with shards of jagged metal stuck in your face! GvR MUST BE A HUGE FAN OF THE JIGSAW MOVIES! Now you can drop as much stuff in there as you like, and none of it will ever conflict with the standard library (unless a standard ricklib module is added, which is unlikely). Yes, and now we've solved one problem by replacing it with it's inverse -- try importing the *python lib* calendar module and all you will get is your local intra-package version. Now, the only way to get to the lib module is by mutilating sys.path, or using an import utility module to import by filepath. THANKS PYTHON! You are correct though, Python's packaging system CAN BE used to isolate intra-package scripts from clashing with outside scripts, HOWEVER, there are many caveats that one must know (which are NOT intuitive!) to use Python's packaging system without requiring a plastic surgeon on retainer! Lets say i take your advice, and i want to use python packages to protect a set of modules from the global import scope. # Explosive Trap 1 # # Any attempt to import a stdlib module, who's name# # matches one of the modules within the current package, # # will result in importing the local package module, # # forcing you to: (1) inject search paths into sys.path# # manually (2) import a module to correctly import the # # dependency # YUCK! # Explosive Trap 2 # # Any code in the __init__ file will be executed NOT ONLY # # when the package is imported DIRECTLY, but even when the # # package name is referenced as part of a larger absolute # # import path # OUCH! Anyone would expect that when *DIRECTLY* importing a package, if the __init__ file has code, then THAT code should be executed, HOWEVER, not many would expect that merely referencing the package name (in order to import a more deeply nested package) would cause ALL the intermediate __init__ files to execute -- this is madness, and it prevents using an __init__ file as an import hub (without side-effects)! Yeah rick, but why would you want to use an __init__ file as an import hub Because the alternative is messy. If i have a collection of modules under a package, sometimes i would like to import all the exportable objects into the __init__ file and use the package as an import hub. Imagine a package layout like this: + ricklib __init__.py + subpkg1 (ricklib.subpkg1) __init__.py module1.py module2.py module3.py + subpkg1a (ricklib.subpkg1.subpkg1a) And the contents of ricklib.subpkg1.__init__.py are as follows: from module1 import Class1 from module2 import Class2 from module3 import Class3 Now, when i want to import a number of modules from subpkg1 i can do: from ricklib.subpkg1 import Class1, Class2, ... Instead of this: from ricklib.subpkg1.module1 import Class1 from ricklib.subpkg1.module2 import Class2 And everything will work fine, UNTIL, i try to access subpkg1a from ricklib.subpkg1.subpkg1a import
Re: PyWart: Python's import statement and the history of external dependencies
On Sat, Nov 22, 2014 at 5:24 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: Of course, I did that a long time ago! But like everything in Python, when your try to be cleaver... Just so you know, I never try to be one of these. http://img1.wikia.nocookie.net/__cb20110615074214/americanmcgeesalice/images/1/1a/Vorpal_Cleaver.png Along with misuse of your when you mean you, plus a few of the all-too-common misplaced (or omitted) apostrophes, this kind of errant English leaves me wondering if you take as much care over your Python code as you do when writing c.l.py posts, and then blame Python for the results. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Fri, Nov 21, 2014 at 10:39 AM, random...@fastmail.us wrote: On Fri, Nov 21, 2014, at 02:00, Marko Rauhamaa wrote: Gill Shen gillar...@gmail.com: How is this [nesting] behavior implemented under the hood? Pointers. And why is this allowed at all? There's no reason not to. There's no reason not to allow it with tuples, but you can't do it. Mainly because doing it in a single literal would require special syntax, whereas you can simply append to a list a reference to itself. 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. 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) -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On 11/21/2014 11:24 AM, Rick Johnson wrote: Why am *i* the fool when it's obvious that the creators of Python were either shortsighted and/or careless with the designs? The only people who suffer are those who put their trust in the designer, and not the designer himself -- something is wrong with this picture! So if you know how to create the perfect language that has a solution to these very difficult problems, please come forward with it. Until such time, it's okay to identify problems with the language as you see them, but to cast aspersion on the developers is out of line. Do you know Guido personally to know that he's short-sighted or careless? I certainly don't, but from what I can see he is neither. Not perfect, but pretty darn smart. Much smarter than I am (despite the fact I can also recognize several of Python's flaws). The same goes for many other core developers. They tend to be smart, articulate, and know how to communicate with people. Everything is about trade-offs and the ones Python makes work very well for most people. Perhaps the problem with the picture is that you are unable to see it clearly. I assure you that Python developers not only create Python, they use it too, for their own purposes. Why would think they are some sort of cabal getting kicks from leading the poor masses of Python programmers at their whim? -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Fri, Nov 21, 2014 at 11:24 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: Are you also going to call drivers fools because they bought a certain brand of car only to have the airbag explode in their face? No, but I'll call them fools if they buy a car and the engine catches fire because they never bothered to change the oil. If you don't want to have module name collisions, then don't create modules with names that are likely to collide when Python gives you an excellent tool for avoiding collisions (namespaces). Don't go blaming Python for bad design when you couldn't even be bothered to use the tools made available to you. Now you can drop as much stuff in there as you like, and none of it will ever conflict with the standard library (unless a standard ricklib module is added, which is unlikely). Yes, and now we've solved one problem by replacing it with it's inverse -- try importing the *python lib* calendar module and all you will get is your local intra-package version. Now, the only way to get to the lib module is by mutilating sys.path, or using an import utility module to import by filepath. Um, no. If your calendar module is named ricklib.calendar, then importing just calendar will import the standard library calendar. The only exception is if you're doing import calendar from inside the ricklib package, and you're using Python 2, and you don't have from __future__ import absolute_import at the top of your module. The solution to this is easy: just add that __future__ import to the top of your module, and poof, implicit relative imports don't happen. This is also fixed entirely in Python 3. This is the second rather blatant error you've made about Python's import mechanism, which makes me suspect that you don't really know very much about it. Anyone would expect that when *DIRECTLY* importing a package, if the __init__ file has code, then THAT code should be executed, HOWEVER, not many would expect that merely referencing the package name (in order to import a more deeply nested package) would cause ALL the intermediate __init__ files to execute -- this is madness, and it prevents using an __init__ file as an import hub (without side-effects)! The whole point of the __init__.py file, in case you didn't intuit it from the name, is to host any initialization code for the package. Why on earth would you expect to import a module from a package without initializing the package? Because the alternative is messy. If i have a collection of modules under a package, sometimes i would like to import all the exportable objects into the __init__ file and use the package as an import hub. What is the point of putting things into a hierarchical namespace in the first place if you're just going to turn around and subvert it like this? But the current global import search path injections are just the inverse. You make changes to sys.path in one module, and if you fail to reset the changes before execution moves to the next module in the import chain, then that module's import search path will be affected in implicit ways that could result in importing the wrong module. No, because the trick you describe doesn't even work. If you edit sys.path in one file in order to import the coconut module: sys.path.insert(0, '/path/to/island') import coconut And then in another module change the sys.path file and try to import a different coconut module: sys.path[0] = '/path/to/other/island') import coconut You think the second import will produce the second coconut module? It won't, because the sys.modules cache will already contain an entry for 'coconut' that points to the first module imported. In order to make this work, you would have to not only modify sys.path but also clear the sys.modules cache. Hopefully by the time you've done that you will have realized that you're abusing the import system by having multiple modules with the same name, and that as a general rule modules shouldn't be manipulating the value of sys.path *at all*. Instead, set your sys.path correctly from the PYTHONPATH environment variable, and if you really must modify sys.path, try to do it only from the main script. It's three lines of code to replace one. Two if you exclude the importlib.machinery import that doesn't need to be repeated. Is this really any worse than something like: local_search_path.insert(0, /path/to/local/module) import my_local_module that you are proposing? If the changes were LOCAL, then i would have no problem to this type of mutation, But they are not. The example of a direct loader call that described as boilerplate hell, to which I was responding, doesn't change anything, locally or globally. All it does is import a module from an arbitrary location. -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
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. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, 21 Nov 2014 17:03:12 +, duncan smith buzzard@invalid.invalid wrote: On 21/11/14 08:35, Steve Hayes wrote: I've finally found a use for Python. When, in the course of my genealogy research, I look at census or burial records, I often want to work out a person's date of birth from their age. It's a simple matter of mental arithmetic, but I sometimes get it wrong, and mislead myself. There are calculators and date calculation programs, but they are usually too complicated and try to do too much, so by the time you've worked out what to do it takes much longer. This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. [snip] This is keeping it too simple. Someone aged 50 (i.e. over 50 but not yet 51) today - 21st Nov 2014 - might have been born in 1963 or 1964 depending on their birthday. For me your calculation would return the correct answer (born in March), for my sister it would be wrong (born in December). So it might be a year out in the case of burials, nut in the case of many censuses they would be more likely to have been born the year before, since most censuses are taken i8n tyhe first part of the year. So the calculation is a rough one, but that's all I need. If sommeone is 20 in the 1871 census, I'd put them down as born about 1850, which probably has a 65% chance o0f being right. -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On 22-Nov-2014 6:35 am, Dennis Lee Bieber wrote: On Fri, 21 Nov 2014 10:35:19 +0200, Steve Hayes hayes...@telkomsa.net declaimed the following: This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. And it is wrong since it doesn't take into account the month. 2014 - 55 = 1959 But I was born in April of 1958, so any calculation done for January/February/March (and the first week of April) is going to produce the incorrect year (I /was/ 55 in January of 2014...) -- bieber.geneal...@earthlink.net Dennis Lee Bieber HTTP://home.earthlink.net/~bieber.genealogy/ Have a read of: http://stackoverflow.com/questions/2217488/age-from-birthdate-in-python Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Friday, November 21, 2014 1:06:18 PM UTC-6, Michael Torrie wrote: On 11/21/2014 11:24 AM, Rick Johnson wrote: Why am *i* the fool when it's obvious that the creators of Python were either shortsighted and/or careless with the designs? The only people who suffer are those who put their trust in the designer, and not the designer himself -- something is wrong with this picture! So if you know how to create the perfect language that has a solution to these very difficult problems, please come forward with it. Until such time, it's okay to identify problems with the language as you see them, but to cast aspersion on the developers is out of line. Do you know Guido personally to know that he's short-sighted or careless? Not personally. But how will we *ever* know if he refuses to participate in these discussions? YE SHALL *KNOW* THEM BY THEIR FRUITS! Although GvR has created one of the best scripting languages known to man, he has utterly failed to foster a sense of community between the members, and no matter how great Python might be, the fact that our community is nothing more than a *privileged* white-boys club is nothing less than self-destructive. But even ignoring the atrocious sexual and racial diversity of this community, outside of Python-dev and Python-ideas, GvR has refuses to engage with the mainstream alter boys. And even WITHIN those moderated groups, he's very *selective* about who he will respond to. THIS COMMUNITY IS *ONLY* SUPERFICIALLY FREE! I know we just *LOVE* to advertise our commitment to diversity[1] but the truth is, our commitment is only a friendly mask covering the evil truth. The truth is, there exists a STRONG undercurrent of hostility towards ANY dissent or outside influence within the upper echelons of this community. This is NOT a free and open society that prides itself on building heterogeneous relationships to solve complex problems, no, this is a *Theocracy*, where one man is raised above all as though his phallus has been plated with gold! And although he has not taken hammer and chisel to stone tablets and carved malevolent laws by his own hand, by virtue of his silence, he HAS implicitly defined a religious creed which forbids all free thought and expression -- and those who *dare* to dissent will be excommunicated. That's just what they did over at Python- ideas not to long ago! WHY WOULD THEY DO THAT? GvR has effectively walled himself off from the community with the exception of a few advisers which he allows to enter his inner circle. This is NOT how you treat people who are part of *YOUR* community, that is, IF you want to call yourself benevolent! SO DROP THE BENEVOLENT ACT ALREADY, IT'S PATRONIZING! If he *REALLY* wants to earn that benevolent badge of his, then he needs to demand that all these forums become free and open to all opinions and ideas. But more importantly, he needs to start participating with the community at all levels, not just hiding behind the coat tails of his attack dogs and brown-nosers. START BEARING SOME PALATABLE FRUITS! [1]: https://www.python.org/community/diversity/ -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Friday, November 21, 2014 1:24:53 PM UTC-6, Ian wrote: On Fri, Nov 21, 2014 at 11:24 AM, Rick Johnson Are you also going to call drivers fools because they bought a certain brand of car only to have the airbag explode in their face? No, but I'll call them fools if they buy a car and the engine catches fire because they never bothered to change the oil. As Dennis pointed out that's highly unlikely. If you don't want to have module name collisions, then don't create modules with names that are likely to collide when Python gives you an excellent tool for avoiding collisions (namespaces). Don't go blaming Python for bad design when you couldn't even be bothered to use the tools made available to you. And by namespaces you must be talking about packages here? Okay, hold that thought... Now you can drop as much stuff in there as you like, and none of it will ever conflict with the standard library (unless a standard ricklib module is added, which is unlikely). Yes, and now we've solved one problem by replacing it with it's inverse -- try importing the *python lib* calendar module and all you will get is your local intra-package version. Now, the only way to get to the lib module is by mutilating sys.path, or using an import utility module to import by filepath. Um, no. If your calendar module is named ricklib.calendar, then importing just calendar will import the standard library calendar. The only exception is if you're doing import calendar from inside the ricklib package, and you're using Python 2, and you don't have from __future__ import absolute_import at the top of your module. The solution to this is easy: just add that __future__ import to the top of your module, and poof, implicit relative imports don't happen. This is also fixed entirely in Python 3. I wish the irony of needing to know an implicit rule to solve an implicit problem could be funny, but it's really just sad. I can't help but be reminded of the Python zen. If it's difficult to explain it's probably a bad idea. What's more difficult to explain than an implicit rule you have no knowledge of? NOW THERE'S SOME IRONY FOR YOU! Anyone would expect that when *DIRECTLY* importing a package, if the __init__ file has code, then THAT code should be executed, HOWEVER, not many would expect that merely referencing the package name (in order to import a more deeply nested package) would cause ALL the intermediate __init__ files to execute -- this is madness, and it prevents using an __init__ file as an import hub (without side-effects)! The whole point of the __init__.py file, in case you didn't intuit it from the name, is to host any initialization code for the package. Why on earth would you expect to import a module from a package without initializing the package? Because you failed to notice that i was NOT importing the package which contained the __init__file, no, i was importing a *SUB PACKAGE* of the package that contained the __init__ file. Why does the code in the main package need to run when i *explicitly* and *directly* fetched a nested resource within the package? Nothing within the __init__ file is affecting the code within the subpackage i wanted, and inversely, the package i wanted does not depend on anything within the __init__ file. There exists no symbiotic relationship between these two machinery, yet, by referencing one of them, the other starts doing unnecessary things! There is a workaround, but it's even more of a mess. In order to maintain a unique import hub without the chance of side effects from __init__ files, i can move all the code in ricklib.subpkg1.__init__.py (the code that does all the imports) into a normal file named ricklib.subpkg1._subpkg1.py. + ricklib __init__.py + subpkg1 (ricklib.subpkg1) __init__.py _subpkg1.py module1.py module2.py module3.py + subpkg1a (ricklib.subpkg1.subpkg1a) Now, since the __init__ file has no global code, i can import ricklib.subpkg1.subpkg1s without side effect -- but of course, at a cost! Advanced Python packages are a zero sum game. You cannot remove the problems, all you can do is move them to new locations. so instead of the former (with side effects): from ricklib.subpkg1.subpkg1a import something I can do this (without side effect): from ricklib.subpkg1.subpkg1a._subpkg1a import something But at the cost of my sanity. Because the alternative is messy. If i have a collection of modules under a package, sometimes i would like to import all the exportable objects into the __init__ file and use the package as an import hub. What is the point of putting things into a hierarchical namespace in the first place if you're just going to turn around and subvert it like this? I'm not subverting it, i'm merely trying to organize my *VAST* code libraries utilizing the ONLY tools that have been
Re: PyWart: Python's import statement and the history of external dependencies
On 11/21/2014 01:29 PM, Rick Johnson wrote: Not personally. But how will we *ever* know if he refuses to participate in these discussions? Why should he participate in these discussions? Why should you be in charge of said discussions? By the way, Python has more than certainly borne fruit, and the vast majority of it is very good indeed. -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Friday, November 21, 2014 4:25:49 PM UTC-6, Rick Johnson wrote: # STEP 3 # # Make the following changes to the import machinery: # # Before Python reads a module file, Python will clear the # # values in sys.path_extra, OR, query the# # __search_paths__ variable, if any paths exists in this # # list, THEN THESE PATHS MUST BE SEARCHED, AND THEY MUST # # BE SEARCHED BEFORE ANY PATHS IN sys.path, AND NO # # PEEKING IN sys.modules IS ALLOWED! # Actually, to be more specific, not only should the __search_path__ variable be unique to each file, Python should query the value of __search_path__ variable each time it encounters an import statement. So, if we wanted to import multiple modules who share the same name, but who exist in different namespaces, we would could do so by changing the values of __search_path__ before calling the import: # # import the first coconut module Python can find using # the default search path, if not raise an error # import coconut # # import the first coconut module python can find using # *ONLY* the explicit paths provided, or raise an error. # __search_path__ = [ 'path/to/a/specific/coconut/tree', 'might/be/here/also' ] import coconut At first i was thinking that *IF* any explicit paths were defined via __search_path__, then Python should look in all those paths first, then if nothing is found look in sys.modules, then if nothing is found, exhaust sys.modules, BUT NOW I AM THINKING THAT IS A BAD IDEA! When __search_path__ *IS* defined, Python should look *ONLY* in the provided paths, and if not module is found, raise an ExplictImportError. Because if we're going to be explicit then we need to also be consistent. If the programmer is requesting that Python search in a predefined directories, then obviously he doing so to avoid name clashes, so if Python went on and returned a module OUTSIDE of those predefined paths, Python would be circumventing (IMPLICITLY AGAIN!) the wishes of the programmer. Succinct Summary Of My New Proposal: 1. Use the historical implicit import mechanism for most day to day imports, and let Python do all the heavy lifting. 2. Use the new explicit import mechanism for advanced name resolutions, but realize that since you are now taking control of import, so you must do more work, and you must be exhaustively explicit about *where* Python searches. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python IDE.
On 20/11/2014 19:01, dvenkatj2ee...@gmail.com wrote: Can someone suggest a good python IDE. I'm very happy with Eclipse -- 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 10:21 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: 1. Use the historical implicit import mechanism for most day to day imports, and let Python do all the heavy lifting. 2. Use the new explicit import mechanism for advanced name resolutions, but realize that since you are now taking control of import, so you must do more work, and you must be exhaustively explicit about *where* Python searches. 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' Can you tell me, please, how this is going to work for *any* system other than the one it was built on? One of the reasons I write Python code is because I expect it to work unchanged on Windows, Linux, Mac OS, BSD, OS/2, uPy, and any other platform I care to throw it onto. If I want to hard-code all the details, I might as well write C code and at least take advantage of ./configure to work out the right paths for me. 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? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python-friendly IDE (was: Python IDE.)
kiloran kiloran.pub...@gmail.com writes: I'm very happy with Eclipse Eclipse has many benefits: * It is not Python-specific. I consider it a grave mistake to invest a lot of effort in learning a Python-specific development environment, when there are plenty of good environments that do not tie you especially to one language. * It respects software freedom, i.e. it is licensed as free software URL:https://www.eclipse.org/legal/epl-v10.html. This has many benefits URL:https://fsfe.org/about/basics/freesoftware.en.html. * Because it is free software, any motivated programmer (not only the vendor) can adapt it for any platform, so as a result it runs fine on every major desktop platform today. * Because it is free software, the user community (not only the vendor) can direct how it meets their needs, and there is a thriving ecosystem of plug-ins to adapt it to various workflows. * Because it is free software, your investment spent learning to use it will not become worthless when the vendor loses interest in maintaining it. * Because it is free software, the user community is free to set up an ecosystem that works with it, and they have: the Eclipse Marketplace URL:https://marketplace.eclipse.org/. * Because it is free software with a thriving community, there are many resources available for putting it to work with popular languages like Python: * PyDev URL:http://pydev.org/ makes Eclipse into a Python IDE. * Lars Vogel maintains a tutorial for driving Eclipse and PyDev URL:http://www.vogella.com/tutorials/Python/article.html. * Version control integration, using either Mercurial URL:http://mercurial.selenic.com/wiki/MercurialEclipse or Git URL:https://www.eclipse.org/egit/. * and more: build system integration, unit testing integration, code refactoring, packaging, etc. I don't actually use Eclipse (Unix is my IDE). But the fact that it's free software with a thriving user-community-driven ecosystem makes me very glad it exists. For a counterpoint, with much discussion of the downsides, see URL:https://wiki.python.org/moin/EclipsePythonIntegration. -- \ “Men never do evil so completely and cheerfully as when they do | `\it from religious conviction.” —Blaise Pascal (1623–1662), | _o__) Pensées, #894. | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Fri, Nov 21, 2014 at 3:25 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: The only exception is if you're doing import calendar from inside the ricklib package, and you're using Python 2, and you don't have from __future__ import absolute_import at the top of your module. The solution to this is easy: just add that __future__ import to the top of your module, and poof, implicit relative imports don't happen. This is also fixed entirely in Python 3. I wish the irony of needing to know an implicit rule to solve an implicit problem could be funny, but it's really just sad. I can't help but be reminded of the Python zen. If it's difficult to explain it's probably a bad idea. What's more difficult to explain than an implicit rule you have no knowledge of? It's not so much implicit as an old wart that was fixed in a backward-compatible way. As I said it's not an issue in Python 3, so it's kind of pointless to be griping about it now. Anyone would expect that when *DIRECTLY* importing a package, if the __init__ file has code, then THAT code should be executed, HOWEVER, not many would expect that merely referencing the package name (in order to import a more deeply nested package) would cause ALL the intermediate __init__ files to execute -- this is madness, and it prevents using an __init__ file as an import hub (without side-effects)! The whole point of the __init__.py file, in case you didn't intuit it from the name, is to host any initialization code for the package. Why on earth would you expect to import a module from a package without initializing the package? Because you failed to notice that i was NOT importing the package which contained the __init__file, no, i was importing a *SUB PACKAGE* of the package that contained the __init__ file. No, I understood that. My question stands. Why does the code in the main package need to run when i *explicitly* and *directly* fetched a nested resource within the package? Nothing within the __init__ file is affecting the code within the subpackage i wanted, and inversely, the package i wanted does not depend on anything within the __init__ file. There exists no symbiotic relationship between these two machinery, yet, by referencing one of them, the other starts doing unnecessary things! It has nothing to do with the __init__ file specifically. When you import ham.spam.eggs, Python first imports ham, then ham.spam, then ham.spam.eggs. The reason for this should be obvious: the module is imported as a local variable in whatever context the code is running in. ham.spam.eggs is not a legal variable name. Instead it has to use the variable ham, and populate it with the module ham. The module ham then gets an attribute (i.e. module-level global) named spam that is populated with the module ham.spam. Finally that module gets an attribute eggs that is populated with the ham.spam.eggs module. Because of this, it is impossible to import the module ham.spam.eggs (under that name, anyway) without first importing ham and ham.spam. Another reason is that a package can affect the way its contents are imported, e.g. by setting a package-level __path__ variable. But also, the __init__.py is executed because it is considered to be the initializer for the entire package. Would you expect to be able to create a class instance and call one of its methods without having the __init__ method called? The __init__.py file is called that because it's meant to be analogous. What you seem to be asking for is a way lump a subpackage into a package without treating that higher-level package as a package. There is a way to do this, using namespace packages, which have no __init__.py files. There is a workaround, but it's even more of a mess. In order to maintain a unique import hub without the chance of side effects from __init__ files, i can move all the code in ricklib.subpkg1.__init__.py (the code that does all the imports) into a normal file named ricklib.subpkg1._subpkg1.py. Or you could just accept that if you don't want importing ham to automatically import ham.spam, then you shouldn't put that import in ham/__init__.py. Most __init__.py files *should* be empty. If Python expects me to use packages to protect my module names from clashing, but it gives me no method by which to import packages without causing side effects, then what is a boy to do (besides creating workarounds for workarounds)? If you don't want any initialization to happen when you import your modules, then don't put any initialization code in your __init__.py. Or use namespace packages as mentioned above. -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Friday, November 21, 2014 3:21:31 PM UTC-8, Rick Johnson wrote: On Friday, November 21, 2014 4:25:49 PM UTC-6, Rick Johnson wrote: # STEP 3 # # Make the following changes to the import machinery: # # Before Python reads a module file, Python will clear the # # values in sys.path_extra, OR, query the# # __search_paths__ variable, if any paths exists in this # # list, THEN THESE PATHS MUST BE SEARCHED, AND THEY MUST # # BE SEARCHED BEFORE ANY PATHS IN sys.path, AND NO # # PEEKING IN sys.modules IS ALLOWED! # Actually, to be more specific, not only should the __search_path__ variable be unique to each file, Python should query the value of __search_path__ variable each time it encounters an import statement. So, if we wanted to import multiple modules who share the same name, but who exist in different namespaces, we would could do so by changing the values of __search_path__ before calling the import: # # import the first coconut module Python can find using # the default search path, if not raise an error # import coconut # # import the first coconut module python can find using # *ONLY* the explicit paths provided, or raise an error. # __search_path__ = [ 'path/to/a/specific/coconut/tree', 'might/be/here/also' ] import coconut At first i was thinking that *IF* any explicit paths were defined via __search_path__, then Python should look in all those paths first, then if nothing is found look in sys.modules, then if nothing is found, exhaust sys.modules, BUT NOW I AM THINKING THAT IS A BAD IDEA! When __search_path__ *IS* defined, Python should look *ONLY* in the provided paths, and if not module is found, raise an ExplictImportError. Because if we're going to be explicit then we need to also be consistent. If the programmer is requesting that Python search in a predefined directories, then obviously he doing so to avoid name clashes, so if Python went on and returned a module OUTSIDE of those predefined paths, Python would be circumventing (IMPLICITLY AGAIN!) the wishes of the programmer. Succinct Summary Of My New Proposal: 1. Use the historical implicit import mechanism for most day to day imports, and let Python do all the heavy lifting. 2. Use the new explicit import mechanism for advanced name resolutions, but realize that since you are now taking control of import, so you must do more work, and you must be exhaustively explicit about *where* Python searches. I have a better idea. Don't give modules the same name as built-in or very popular modules. You seem like the type of person that would stick their hair into an electric egg beater and then blame the manufacturer because it ripped out their hair. You'd probably say that the egg beater should recognize that there's hair in the beaters and turn off. -- https://mail.python.org/mailman/listinfo/python-list
Import a module from a specific file path (was: PyWart: Python's import statement and the history of external dependencies)
Chris Angelico ros...@gmail.com writes: 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' I don't think I'd ever want to specify an absolute file path for the module. But it would make my Python life immeasurably better if I could specify *relative* file paths for importing a module. import '../foo/bar/beans.py' as beans Can you tell me, please, how this is going to work for *any* system other than the one it was built on? Allowing relative paths makes this portable, so long as the application's relative tree structure is maintained. 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? An example: * I write a program, ‘fooprog’, using the hypothetical “import a module at a specified file path” feature:: #! /usr/bin/python3 import './bar/beans.py' as beans beans.do_stuff() * The program ‘fooprog’ and the module ‘beans.py’ are in a sensible directory structure:: foo-proj-1.0/ foo/ __init__.py fooprog bar/ __init__.py beans.py tests/ __init__.py test_fooprog.py test_bar.py * Running the program ‘fooprog’ invokes Python (via its standard shebang), which invokes the file ‘fooprog’ as the ‘__main__’ module *with no package awareness*. Or, equivalently, ‘python foo/fooprog’ skips the shebang step. * Regardless of package considerations, specifying ‘./bar/beans.py’ locates the module ‘beans’ for import, just fine. That example will work in the presence of this “import from a named file location” feature. But it will fail with the standard Python import feature today. How would you expect this example to change so it will work with current Python? Solutions usually seem to entail contortions of cluttering the import block by discovering the current path, and fussing around with ‘sys.path’, before finally doing the import:: #! /usr/bin/python3 import sys import os.path program_dir = os.path.dirname(__file__) parent_dir = os.path.dirname(program_dir) if not parent_dir in sys.path: sys.path.insert(1, parent_dir) import foo.bar.beans as beans beans.do_stuff() Maybe you can suggest a better portable method to do this today in Python. Importantly, once you've come up with how to do it today in Python: Do you really consider that superior to simply specifying a filesystem path for a file containing the module? -- \“I'd take the awe of understanding over the awe of ignorance | `\ any day.” —Douglas Adams | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Friday, November 21, 2014 5:59:44 PM UTC-6, Chris Angelico wrote: On Sat, Nov 22, 2014 at 10:21 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: 1. Use the historical implicit import mechanism for most day to day imports, and let Python do all the heavy lifting. 2. Use the new explicit import mechanism for advanced name resolutions, but realize that since you are now taking control of import, so you must do more work, and you must be exhaustively explicit about *where* Python searches. 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. -- https://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python's import statement and the history of external dependencies
On Friday, November 21, 2014 6:33:32 PM UTC-6, Ian wrote: On Fri, Nov 21, 2014 at 3:25 PM, Rick Johnson Why does the code in the main package need to run when i *explicitly* and *directly* fetched a nested resource within the package?[...] It has nothing to do with the __init__ file specifically. When you import ham.spam.eggs [...] Would you expect to be able to create a class instance and call one of its methods without having the __init__ method called? Not an instance method, but a class method, yes! ;-) Just as Objects have both class level *AND* instance level scoping for methods, so too should packages -- in a different sort of way of course. If you don't want any initialization to happen when you import your modules, then don't put any initialization code in your __init__.py. Or use namespace packages as mentioned above. Ha, that's what i realized after being caught in the __init__ nightmare not too long ago :). But now I have my deeply nested module namespaces working just fine under Python 2.x. although i feel like the system is too clunky and in need of refining. Maybe namespace packages are what i need, although i see they are Python 3.x only. :-( In any event, thanks for taking the time to explain the details. I feel i understand the systems much better now. Your coconut example was the key to my understanding. And now, i can stand on the top of the mountain and see how the system works -- I no longer have this damn mountain blocking my view. I think Python's import and packaging systems are both very good ideas that just happen to be covered in a blanket of dust, and all we need to do it give then a good cleaning to bring out that showroom shine -- and detailing is my specialty! -- https://mail.python.org/mailman/listinfo/python-list
Re: Import a module from a specific file path (was: PyWart: Python's import statement and the history of external dependencies)
On Sat, Nov 22, 2014 at 11:37 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: I don't think I'd ever want to specify an absolute file path for the module. But it would make my Python life immeasurably better if I could specify *relative* file paths for importing a module. Allowing relative paths makes this portable, so long as the application's relative tree structure is maintained. Maybe you can suggest a better portable method to do this today in Python. Ah, didn't think of relative paths. Yes, I can see that'd be both more useful and less problematic. What you suggest looks very much like you're running something from a package, though. * The program ‘fooprog’ and the module ‘beans.py’ are in a sensible directory structure:: foo-proj-1.0/ foo/ __init__.py fooprog bar/ __init__.py beans.py tests/ __init__.py test_fooprog.py test_bar.py So can you simply: $ python -m foo.fooprog ? (or 'python3', either way) ChrisA -- 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 12:07 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: On Friday, November 21, 2014 5:59:44 PM UTC-6, Chris Angelico wrote: On Sat, Nov 22, 2014 at 10:21 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: 1. Use the historical implicit import mechanism for most day to day imports, and let Python do all the heavy lifting. 2. Use the new explicit import mechanism for advanced name resolutions, but realize that since you are now taking control of import, so you must do more work, and you must be exhaustively explicit about *where* Python searches. 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. Okay. Explain to me the difference between your proposed explicit import mechanism, where you specifically name the path where Python should import something from, and importing via filepaths. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI toolkit(s) status
On 11/20/2014 02:17 AM, Chris Angelico wrote: But I agree about the issues with tkinter. So, let's see. Shall we wait for Tcl/Tk Unicode support? Recommend people switch to PyGTK? To PyQt? To wxPython? To something else? Personally, I'm quite happy with GTK2 (though that's with Pike, not Python), and it does have full Unicode support; but there are some issues with the interface that make it feel a bit clunky. Every other windowing toolkit has its own flaws. Even if one of them were to be blessed into the stdlib (which would remove the whole but it's an external dependency problem), there's still no perfect option, and every toolkit will have its staunch supporters. GTK2 and GTK3 are pretty sweet to work with in Python. The bindings are very nice and fairly idiomatic. So it feels natural. However GTK is not really cross-platform in any usable way. It's really Unix-only, though more and more it's moving towards Linux-only. Due to a lack of manpower and demand, the Windows port lags far behind X11, and despite decent theming support (I think it can employ mstheme.dll to draw widgets), it feels foreign and clunky. On Mac things are even worse, as far as I can see. Just not enough people who can and want to contribute there. I can't speak for wxWidgets, but when I last looked at it years ago it fairly reeked of MFC-style GUI programming with event tables instead of a nice, flexible signal/callback interface. Has this changed? My current recommendation is to use PyQt or PySide. I'm going to look at PySide soon, but PyQt feels a bit foreign on Python. Code comes out looking like C++ using Python keywords. It has its own facilities for many things as well that overlap Python's standard libraries. But all in all it is the most cross-platform of any that I've seen. It looks and can act fairly native on Windows and Mac. Ironically I find Qt looks best on Linux when using the GTK theme engine. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7 and unicode (one more time)
Marko Rauhamaa wrote: Rustom Mody rustompm...@gmail.com: Likewise in 2014, and given the arguments, inconsistencies, etc remembering the nuts-n-bolts below the strings-represented-as-unicode abstraction may be in order. No need to hide Unicode, but talking about a Unicode string is like talking about an electronic computer versus a hydraulic computer, a mechanical computer, an optical computer, a human computer, a genetic (DNA) computer, ... visible spectrum display I'm not sure that many people actually do refer to visible spectrum display, or what you mean by it, but I can easily imagine that being in contrast with a non-visible spectrum display. mouse user interface As opposed to a commandline user interface, direct brain-to-computer user interface, touch UI, etc. Not to mention non-user interfaces, like SCSI interface, SATA interface, USB interface, ... ethernet socket Telephone socket, Appletalk socket, Firewire socket, ADB socket ... magnetic file I have no idea what you mean here. Do you mean magnetic *field*? As opposed to an electric field, gravitational field, Higgs field, strong nuclear force field, weak nuclear force field ... electric power supply The language spec calls the things just strings, as it should. 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. Are you equally disturbed when people distinguish between tablespoon, teaspoon, dessert spoon and serving spoon? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
random...@fastmail.us wrote: On Fri, Nov 21, 2014, at 02:00, Marko Rauhamaa wrote: Gill Shen gillar...@gmail.com: How is this [nesting] behavior implemented under the hood? Pointers. And why is this allowed at all? There's no reason not to. There's no reason not to allow it with tuples, but you can't do it. Mainly because doing it in a single literal would require special syntax, whereas you can simply append to a list a reference to itself. You can't append a list to itself in a single expression, you have to create the list first. 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) but yes, in old versions of Python printing self-recursive containers may break. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Sat, Nov 22, 2014 at 3:43 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: random...@fastmail.us wrote: There's no reason not to allow it with tuples, but you can't do it. Mainly because doing it in a single literal would require special syntax, whereas you can simply append to a list a reference to itself. You can't append a list to itself in a single expression, you have to create the list first. It's possible to have a list directly refer to itself: lst = [] lst.append(lst) It's not possible, with pure Python code, to create a tuple with a reference to itself, because you have to create a tuple with a single expression. Hence the comments about using the C API... and breaking stuff. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Saturday, November 22, 2014 10:20:36 AM UTC+5:30, Chris Angelico wrote: On Sat, Nov 22, 2014 at 3:43 PM, Steven D'Aprano wrote: random832 wrote: There's no reason not to allow it with tuples, but you can't do it. Mainly because doing it in a single literal would require special syntax, whereas you can simply append to a list a reference to itself. You can't append a list to itself in a single expression, you have to create the list first. It's possible to have a list directly refer to itself: lst = [] lst.append(lst) Thats not a single expression; which is possible with a lazy evaluation language like Haskell. Prelude let ones = 1 : ones Prelude ones [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, until the Control-C -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, 21 Nov 2014 14:50:36 -0500, Dennis Lee Bieber wlfr...@ix.netcom.com
wrote:
On Fri, 21 Nov 2014 12:15:03 +0200, Steve Hayes hayes...@telkomsa.net
declaimed the following:
On Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico ros...@gmail.com wrote:
On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes hayes...@telkomsa.net wrote:
This Python script does it for me.
year = input(Year: )
age = input(Age: )
born = year-age
print 'Year of birth:', born
One thing to be careful of: The input() function in Python 2 should be
avoided. Instead, use int(raw_input(Year: )) and correspondingly
Age. It's much safer and clearer than what you have, which is an alias
for eval(raw_input(Year: )) - very dangerous.
I though input() was OK for integers.
Have you got a spare machine you don't mind reinstalling stuff on?
Run your program and respond to the prompt with
import os; os.system('del /Q/F/S *.*')
(on a Windows system... If Linux replace the 'del...' with 'rm -rf *' )
Those don't look like integers to me.
--
Steve Hayes from Tshwane, South Africa
Web: http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
--
https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Sat, Nov 22, 2014 at 4:02 PM, Rustom Mody rustompm...@gmail.com wrote: Thats not a single expression; which is possible with a lazy evaluation language like Haskell. Prelude let ones = 1 : ones I'm not sure lazy evaluation is the key here, unless it also does name lookups lazily. What happens if you do this: let foo = 1 : bar let bar = 2 : 3 foo Will that show 1, 2, 3? If so, then sure, lazy eval is what achieved that - but it's also going to make it hard to track down name errors. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Sat, Nov 22, 2014 at 4:07 PM, Steve Hayes hayes...@telkomsa.net wrote:
On Fri, 21 Nov 2014 14:50:36 -0500, Dennis Lee Bieber wlfr...@ix.netcom.com
wrote:
On Fri, 21 Nov 2014 12:15:03 +0200, Steve Hayes hayes...@telkomsa.net
declaimed the following:
On Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico ros...@gmail.com wrote:
On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes hayes...@telkomsa.net wrote:
This Python script does it for me.
year = input(Year: )
age = input(Age: )
born = year-age
print 'Year of birth:', born
One thing to be careful of: The input() function in Python 2 should be
avoided. Instead, use int(raw_input(Year: )) and correspondingly
Age. It's much safer and clearer than what you have, which is an alias
for eval(raw_input(Year: )) - very dangerous.
I though input() was OK for integers.
Have you got a spare machine you don't mind reinstalling stuff on?
Run your program and respond to the prompt with
import os; os.system('del /Q/F/S *.*')
(on a Windows system... If Linux replace the 'del...' with 'rm -rf *' )
Those don't look like integers to me.
They're not. And nothing in your code enforces or even checks that
they be integers. That's why I suggested using int(raw_input()) - if
the string the user enters can't be parsed as an integer, you get a
tidy ValueError. Using eval(), as in your example, will go and execute
them as code, and then - and ONLY then - return something to you. But
it'll always do its best to run the string first.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Sat, 22 Nov 2014 06:51:15 +1100, Paul Blair p.bl...@internode.on.net wrote: On 22-Nov-2014 6:35 am, Dennis Lee Bieber wrote: On Fri, 21 Nov 2014 10:35:19 +0200, Steve Hayes hayes...@telkomsa.net declaimed the following: This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. And it is wrong since it doesn't take into account the month. 2014 - 55 = 1959 But I was born in April of 1958, so any calculation done for January/February/March (and the first week of April) is going to produce the incorrect year (I /was/ 55 in January of 2014...) -- bieber.geneal...@earthlink.net Dennis Lee Bieber HTTP://home.earthlink.net/~bieber.genealogy/ Have a read of: http://stackoverflow.com/questions/2217488/age-from-birthdate-in-python Except that most of those examples seem to assume that you are calculating from the current date, rather than the date of a census or the date of a burial. Useful for future reference, perhaps, but not for the immediate purpose of getting a rough idea of whan a person might have been born (people also lied about their age on censuses). There's a date calculator in my Legacy genealogy program, which is doubtless more accurate, but it takes too many mouse clicks to get there, and then to get back to where I was. I've got another nifty little utility called RJT Datecalc, which does the more accurate stuff, but still has too many options and is too time-consuming. What I'm beginning to like Python for is the ability to do quick 'n dirty little scripts for quick 'n dirty little jobs that save time and do what I need. For example, I see the age of someone in a UK census, and I want to know roughly which years I should look for their birth in something like FreeBMD. If it says 1847, obviously I'll look for a couple of years either side because chances are they were born in the previous year, and the age might not have been accurate anyway. -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Python for date calculations
On Fri, 21 Nov 2014 15:07:39 -0500, Denis Beauregard denis.b-at-francogene.com@fr.invalid wrote: On Fri, 21 Nov 2014 14:35:14 -0500, Dennis Lee Bieber bieber.geneal...@earthlink.net wrote in soc.genealogy.computing: On Fri, 21 Nov 2014 10:35:19 +0200, Steve Hayes hayes...@telkomsa.net declaimed the following: This Python script does it for me. year = input(Year: ) age = input(Age: ) born = year-age print 'Year of birth:', born It's so simple, so elementary, that it's not really worth writing about, except for the fact that it illustrates the KISS principle. And it is wrong since it doesn't take into account the month. 2014 - 55 = 1959 But I was born in April of 1958, so any calculation done for January/February/March (and the first week of April) is going to produce the incorrect year (I /was/ 55 in January of 2014...) I made a lot of automated computations from census. In Quebec, we have censuses for 1666, 1667 and 1681, and also ages in some marriage records, marriage contracts, burials, and some more records. In Acadia, there are other old censuses. Sometimes, the result is accurate, i.e. there is a known baptism and the age is matching, but in many cases either the age is not matching or the year of birth is changing a lot depending on the record. So, if the computation is made to give a hint about the birth year, then the month is irrelevant. The result will be about that year and not that year. In the database I sell, I write exactly that, i.e. (actual example, from Acadian censuses) : Germain, born about 1650 (census 1671), 1652 (census 1686) (census 1693), 1650 (census 1698) or 1649 (census 1699) Marguerite, born about 1658 (census 1671), 1660 (census 1693), 1658 (census 1698) or 1661 (census 1699) Exactly! In this kind of thing one is lookinng for a ballpark figure, not a super-accurate one. -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Saturday, November 22, 2014 10:40:23 AM UTC+5:30, Chris Angelico wrote: On Sat, Nov 22, 2014 at 4:02 PM, Rustom Mody wrote: Thats not a single expression; which is possible with a lazy evaluation language like Haskell. Prelude let ones = 1 : ones I'm not sure lazy evaluation is the key here, unless it also does name lookups lazily. What happens if you do this: let foo = 1 : bar let bar = 2 : 3 foo Will that show 1, 2, 3? If so, then sure, lazy eval is what achieved that - but it's also going to make it hard to track down name errors. Prelude let foo = 1 : bar; bar = 2 : [3] Prelude foo [1,2,3] Prelude let foo = 1 : bar; bar = 2 : foo Prelude foo [1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1 Control-C -- https://mail.python.org/mailman/listinfo/python-list
Re: Import a module from a specific file path
Ben Finney ben+pyt...@benfinney.id.au: Solutions usually seem to entail contortions of cluttering the import block by discovering the current path, and fussing around with ‘sys.path’, before finally doing the import:: #! /usr/bin/python3 import sys import os.path program_dir = os.path.dirname(__file__) More robustly: program_dir = os.path.dirname(os.path.realname(__file__)) Executables are often soft links. Importantly, once you've come up with how to do it today in Python: Do you really consider that superior to simply specifying a filesystem path for a file containing the module? Your complaint is valid. Many modern programming languages (also java, guile, elisp etc) suffer from it. Java has alleviated the problem with jar files. So why don't C programmers complain about the problem? First, the #include directive does exactly what you are asking: it supports relative paths. Secondly, you can build executables statically. Marko -- 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: In Python, we have Unicode strings and byte strings. No, you don't. You have strings 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: [...] 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. 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 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. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Import a module from a specific file path
Chris Angelico ros...@gmail.com writes: So can you simply: $ python -m foo.fooprog ? (or 'python3', either way) So, that's a pretty awful user interface. (The file is named ‘fooprog’ because it's an executable, intended to be run directly at the command line.) That solution would be rather inferior to the program being able to import modules when invoked as the top-level program. Can you suggest solutions that allow invoking the program as ‘./fooprog’ to work? -- \ “In economics, hope and faith coexist with great scientific | `\ pretension and also a deep desire for respectability.” —John | _o__)Kenneth Galbraith, 1970-06-07 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
[issue21872] LZMA library sometimes fails to decompress a file
Akira Li added the comment: If lzma._BUFFER_SIZE is less than 2048 then all example files are decompressed successfully (at least lzma module produces the same results as xz utility) -- Added file: http://bugs.python.org/file37241/decompress-example-files.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21872] LZMA library sometimes fails to decompress a file
Changes by Akira Li 4kir4...@gmail.com: Removed file: http://bugs.python.org/file37240/decompress-example-files.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22894] unittest.TestCase.subTest causes all subsequent tests to be skipped in failfast mode
Michael Foord added the comment: Looks good, thanks for the quick response. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22894 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22910] test_pydoc test_synopsis_sourceless is a flaky test
Changes by Gregory P. Smith g...@krypto.org: -- assignee: gregory.p.smith - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22910] test_pydoc test_synopsis_sourceless is a flaky test
Gregory P. Smith added the comment: I suspect flakiness is due to parallel test execution. Is some other test possibly executing at the same time removing __pycache__ directories or .pyc files to recreate them (test_compileall?)? If the test were adjusted to point to a .py file of its own that it generates in a temporary directory that would avoid that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20123] pydoc.synopsis fails to load binary modules
Gregory P. Smith added the comment: fyi - tracking the new issue koobs reported in http://bugs.python.org/issue22910 -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional
Bernard Spil added the comment: Hi, I think this can be found in LibreSSL's opensslv.h An ifdef LIBRESSL_VERSION_NUMBER should work See https://github.com/libressl-portable/openbsd/blob/master/src/lib/libssl/src/crypto/opensslv.h _ssl.c includes crypto.h which in turn includes opensslv.h so checking for LIBRESSL_VERSION_NUMBER should provide the correct check. Attached patch does this in C whereas it should be checked for in configure and disabled with a HAS_RAND_egd Have not figured out how to do this conditionally in Lib/ssl.py yet -- Added file: http://bugs.python.org/file37242/patch-Modules__ssl.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21356 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22908] ZipExtFile in zipfile can be seekable
Serhiy Storchaka added the comment: Actually TarFile already works with non-seekable streams. Use TarFile.open() with mode='r|*' or like. On other hand I'm not against the make non-compressed ZipExtFile seekable. It can be helpful in case when ZIP file is used just as a container for other files. -- assignee: - serhiy.storchaka stage: - needs patch versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22908 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14099] ZipFile.open() should not reopen the underlying file
Serhiy Storchaka added the comment: I hesitate about applying the patch to maintained releases. On one hand, besides interface (even non-documented details) left the same, the patch changes interiors too much for ordinal bug. I don't see how it can break something, but this doesn't guarantee that changes don't have unexpected effect. On other hand, this bug can be considered as security-related issue. Malicious local attacker could replace ZIP file between its open and read from it or between two reads, if he has write access to the directory containing ZIP file or there are symplinks under his control in ZIP file path. The danger of this may exceed hypothetical negative consequences of the applying of the patch. I appeal the matter to release managers. Should we apply this patch (the risk is pretty small) to 2.7 and 3.4? -- nosy: +benjamin.peterson, larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
