Re: Import a module from a specific file path
Chris Angelico 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
Re: python 2.7 and unicode (one more time)
Steven D'Aprano : > 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: [...] 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. 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
Ben Finney : > 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: 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 -- 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 wrote: >On Fri, 21 Nov 2014 14:35:14 -0500, Dennis Lee Bieber > wrote in soc.genealogy.computing: > >>On Fri, 21 Nov 2014 10:35:19 +0200, Steve Hayes >>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: Using Python for date calculations
On Sat, 22 Nov 2014 06:51:15 +1100, Paul Blair wrote: >On 22-Nov-2014 6:35 am, Dennis Lee Bieber wrote: >> On Fri, 21 Nov 2014 10:35:19 +0200, Steve Hayes >> 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 Sat, Nov 22, 2014 at 4:07 PM, Steve Hayes wrote: > On Fri, 21 Nov 2014 14:50:36 -0500, Dennis Lee Bieber > wrote: > >>On Fri, 21 Nov 2014 12:15:03 +0200, Steve Hayes >>declaimed the following: >> >>>On Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico wrote: >>> On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes 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: Infinitely nested containers
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. ChrisA -- 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 wrote: >On Fri, 21 Nov 2014 12:15:03 +0200, Steve Hayes >declaimed the following: > >>On Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico wrote: >> >>>On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes 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 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, -- https://mail.python.org/mailman/listinfo/python-list
Re: Infinitely nested containers
On Sat, Nov 22, 2014 at 3:43 PM, Steven D'Aprano 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
random...@fastmail.us wrote: > On Fri, Nov 21, 2014, at 02:00, Marko Rauhamaa wrote: >> Gill Shen : >> >> > 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: python 2.7 and unicode (one more time)
Marko Rauhamaa wrote: > Rustom Mody : > >> 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: 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: PyWart: "Python's import statement and the history of external dependencies"
On Sat, Nov 22, 2014 at 12:07 PM, Rick Johnson 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 >> 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: 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 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 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: 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 > 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
Import a module from a specific file path (was: PyWart: "Python's import statement and the history of external dependencies")
Chris Angelico 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 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
Re: PyWart: "Python's import statement and the history of external dependencies"
On Fri, Nov 21, 2014 at 3:25 PM, Rick Johnson 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
Python-friendly IDE (was: Python IDE.)
kiloran 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 https://www.eclipse.org/legal/epl-v10.html>. This has many benefits 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 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 http://pydev.org/> makes Eclipse into a Python IDE. * Lars Vogel maintains a tutorial for driving Eclipse and PyDev http://www.vogella.com/tutorials/Python/article.html>. * Version control integration, using either Mercurial http://mercurial.selenic.com/wiki/MercurialEclipse> or Git 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 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 Sat, Nov 22, 2014 at 10:21 AM, Rick Johnson 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
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 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: 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 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
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: 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 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: Using Python for date calculations
On Fri, 21 Nov 2014 17:03:12 +, duncan smith 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: Infinitely nested containers
On Fri, Nov 21, 2014 at 12:37 PM, Ian Kelly 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: PyWart: "Python's import statement and the history of external dependencies"
On Fri, Nov 21, 2014 at 11:24 AM, Rick Johnson 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: 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: Infinitely nested containers
On Fri, Nov 21, 2014 at 10:39 AM, wrote: > On Fri, Nov 21, 2014, at 02:00, Marko Rauhamaa wrote: >> Gill Shen : >> >> > 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 Sat, Nov 22, 2014 at 5:24 AM, Rick Johnson 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: 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 t
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: Infinitely nested containers
On Sat, Nov 22, 2014 at 4:39 AM, 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: PyWart: "Python's import statement and the history of external dependencies"
On Fri, Nov 21, 2014 at 9:12 AM, Tim Chase 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 "", line 1, in File "/home/ikelly/p1/m1.py", line 1, in 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 Fri, Nov 21, 2014, at 02:00, Marko Rauhamaa wrote: > Gill Shen : > > > 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: Infinitely nested containers
On Thu, Nov 20, 2014 at 10:54 PM, Gill Shen 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: Most gratuitous comments
On 2014-11-21, Marko Rauhamaa 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-900 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: python 2.7 and unicode (one more time)
On Sat, Nov 22, 2014 at 3:36 AM, Marko Rauhamaa 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: python 2.7 and unicode (one more time)
Rustom Mody : > 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 docs disappointing
On 2014-11-20, Steven D'Aprano 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: 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 2.7 and unicode (one more time)
On Sat, Nov 22, 2014 at 3:11 AM, Francis Moreau 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: 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 > 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 "", line 1, in >>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 b"whatever" 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 "", line 1, in > 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 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 > > " 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: Using Python for date calculations
On 21/11/2014 15:50, Steve Hayes wrote: On Fri, 21 Nov 2014 10:20:06 +, Mark Lawrence 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 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: 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: 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. 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: 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 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: python 2.7 and unicode (one more time)
On Sat, Nov 22, 2014 at 2:23 AM, Steven D'Aprano wrote: > Chris Angelico wrote: > >> On Fri, Nov 21, 2014 at 11:32 AM, Steven D'Aprano >> 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: PyWart: "Python's import statement and the history of external dependencies"
On Thu, Nov 20, 2014 at 8:53 PM, 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. 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: 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: python 2.7 and unicode (one more time)
Chris Angelico wrote: > On Fri, Nov 21, 2014 at 11:32 AM, Steven D'Aprano > 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
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: 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: 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: 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: Using Python for date calculations
On Sat, Nov 22, 2014 at 12:58 AM, 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: *.sdf database access
On Saturday, April 21, 2012 6:55:55 AM UTC-4, Alex Willmer wrote: > On Apr 19, 9:18 pm, Page3D 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 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: 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: 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
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?
On Fri, 21 Nov 2014 12:10:21 +, Juan Christian wrote: > On Fri Nov 21 2014 at 8:05:30 AM alister > > 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? > On Fri Nov 21 2014 at 8:05:30 AM alister < href="mailto:alister.nospam.w...@ntlworld.com";>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? 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
Re: How to access Qt components loaded from file?
On Fri Nov 21 2014 at 8:05:30 AM alister 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: Python Logging and printf()
On Fri, Nov 21, 2014 at 9:48 PM, Ganesh Pal 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: 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 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
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: Using Python for date calculations
On Fri, Nov 21, 2014 at 9:33 PM, alister 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
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, 21 Nov 2014 12:15:03 +0200, Steve Hayes wrote: > On Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico > wrote: > >>On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes >>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: 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, Nov 21, 2014 at 9:20 PM, Mark Lawrence 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: 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 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 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: Using Python for date calculations
On Fri, Nov 21, 2014 at 9:15 PM, Steve Hayes wrote: > On Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico wrote: > >>On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes 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 Fri, 21 Nov 2014 19:40:22 +1100, Chris Angelico wrote: >On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes 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: 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 > > 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 > On Thu Nov 20 2014 at 8:20:29 PM alister < href="mailto:alister.nospam.w...@ntlworld.com";>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? -- Use the Force, Luke. -- 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: Using Python for date calculations
On Fri, Nov 21, 2014 at 7:35 PM, Steve Hayes 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
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: python 2.7 and unicode (one more time)
On Fri, Nov 21, 2014 at 7:16 PM, Marko Rauhamaa wrote: > Chris Angelico : > >> 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
Re: python 2.7 and unicode (one more time)
Chris Angelico : > 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: GUI toolkit(s) status
Am 21.11.14 05:49, schrieb Paul Rubin: Terry Reedy 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