Matplotlib and optimization tutorials at PyCon US
Hi, I will be giving a matplotlib and a optimization tutorial at PyCon in March. The first tutorial is a compact introduction to matplotlib. The optimization tutorial gives an overview over this topic. BTW, the early bird deadline is today. Mike Plotting with matplotlib Instructor: Mike Müller Type:Tutorial Audience level:Novice Category:Useful libraries March 8th 9 a.m. – 12:20 p.m. https://us.pycon.org/2012/schedule/presentation/238/ When it comes to plotting with Python many people think about matplotlib. It is widely used and provides a simple interface for creating a wide variety of plots from very simple diagrams to sophisticated animations. This tutorial is a hands-on introduction that teaches the basics of matplotlib. Students will learn how to create publication-ready plots with just a few lines of Python. Faster Python Programs through Optimization --- Instructor: Mike Müller Type:Tutorial Audience level:Experienced Category:Best Practices/Patterns March 7th 9 a.m. – 12:20 p.m. https://us.pycon.org/2012/schedule/presentation/245/ This tutorial provides an overview of techniques to improve the performance of Python programs. The focus is on concepts such as profiling, difference of data structures and algorithms as well as a selection of tools and libraries that help to speed up Python. -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Distributing methods of a class across multiple files
lh lhughe...@gmail.com wrote: Is this possible please? I have done some searching but it is hard to narrow down Google searches to this question. What I would like to do is, for example: 1) define a class Foo in file test.py... give it some methods 2) define a file test2.py which contains a set of methods that are methods of class Foo defined in test.py. I can import Foo obviously but it isn't clear to me how to identify the methods in test2.py to be methods of class Foo defined in test.py (normally I would just indent them def's under the class but the class isn't textually in test2.py). In short I would like to distribute code for one class across multiple files so a given file doesn't get ridiculously long. I take the point of the other responders that it is not a normal thing to do, but I had a few long but rarely used methods which I wanted to move out of the main file just to keep the main file tidier. I came up with this solution, and it seems to work. In test2.py - def long_method_1(): pass def long_method2(): pass In test.py - import test2 class Foo: long_method_1 = test2.long_method_1 long_method_2 = test2.long_method_2 Then in Foo I can refer to self.long_method_1(). HTH Frank Millman -- http://mail.python.org/mailman/listinfo/python-list
Jobs for developers
Hi There, We are looking to hire talented developers to join different teams.. The candidate should be willing to move to Dubai, United Arab Emirates. The developer must have: 1. Experience in OOP. 2. Strong algorithm thinking. 3. average SQL database design skills. 4. Experience dealing with an MVC framework such as Symfony, Django, RoR or others is a plus. 5. Experience in Python is a plus. 6. Previous experience in a low level programming language such as Java, C++, C# is a huge bonus. 7. Web development experience is a huge bonus. The candidate should be self motivated, love to learn and up for bigger challenges every day. Environment is fast moving and highly demanding. It's a publishing company and being on time and target is the most important factor in what we do plus we push so hard to implement the right design patterns in everything we do. The candidate should be able to think fast and find creative solutions fast while still go for the highest performance solution (fastest algorithms- lowest complexity ) and be able to work with a highly knowledgable team to share and think together. Everyone who joins our team learn so much because it's a company of 600 highly creative individuals and we are up to compete in the market in all of our products so you must be able to work under pressure and enjoy growing in experience and grow with us. If you are up for the journey please email your CV to r...@itpshare.com Visa, insurance, tickets, etc. are all provided. Salary is TBD. ** -- http://mail.python.org/mailman/listinfo/python-list
Re: unittest and threading
On Tue, 2012-01-24 at 13:54 -0800, Ross Boylan wrote: Is it safe to use unittest with threads? In particular, if a unit test fails in some thread other than the one that launched the test, will that information be captured properly? A search of the net shows a suggestion that all failures must be reported in the main thread, but I couldn't find anything definitive. If it matters, I'm using CPython 2.7. Thanks. If you're using email, I'd appreciate a cc. Ross Boylan Steven D'Aprano wrote I think you need to explain what you mean here in a little more detail. If you mean, I have a library that uses threads internally, and I want to test it with unittest, then the answer is almost certainly yes it is safe. If you mean, I want to write unit tests which use threads as part of the test, then the answer again remains almost certainly yes it is safe. Thanks for your responses (only partially excerpted above). The code I want to test uses threads, but that is not entirely internal from the standpoint of the unit test framework. The unit test will be executing in one thread, but some of the assertions may occur in other threads. The question is whether that will work, in particular whether assertion failures will be properly captured and logged by the test framework. Concretely, a test may exercise some code that triggers a callback; the callback might come in a different thread, and the code that is triggered might make various assertions. There are two issues: whether assertions and their failures that happen in other threads will be correctly received by the test framework, and whether the framework is robust against several assertions being raised simultaneously in different threads. The latter seems a bit much to hope for. I assume that, at a minimum, the my test code will need to use locks or other coordination mechanisms so the test doesn't end before all code under test executes. Finally, I'll mention two senses of threads in tests that my question does not concern, although they are also interesting. I am not concerned with testing the performance of my code, in the sense of asserting that an operation must complete before x seconds or after y seconds. Some potential implementations of such tests might use threads even if the code under test was single-threaded. The question also does not concern running lots of unit tests in parallel. Ross -- http://mail.python.org/mailman/listinfo/python-list
search google with python
Hi all, i'ld like to make a simple program for searching images from python. All it have to do is make a search in google images and return the link of the images (20 images is enough i think) Is there any API or modules i can use? Thanks a lot Nico -- http://mail.python.org/mailman/listinfo/python-list
Algorithms in Python
Is there any book or site on python algorithms which asks more and teaches less, I don't want to get bored, and at the same time I want to learn and act more. I use ubuntu. (just in case if its needed). #ALGORITHMS -- Chetan H Harjani IIT Delhi -- http://mail.python.org/mailman/listinfo/python-list
Re: search google with python
On Wed, Jan 25, 2012 at 1:55 AM, Tracubik affdfsdfds...@b.com wrote: Hi all, i'ld like to make a simple program for searching images from python. All it have to do is make a search in google images and return the link of the images (20 images is enough i think) Is there any API or modules i can use? https://developers.google.com/image-search/v1/jsondevguide http://docs.python.org/library/json.html http://docs.python.org/library/urllib2.html Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: search google with python
Il Wed, 25 Jan 2012 02:27:18 -0800, Chris Rebert ha scritto: On Wed, Jan 25, 2012 at 1:55 AM, Tracubik affdfsdfds...@b.com wrote: Hi all, i'ld like to make a simple program for searching images from python. All it have to do is make a search in google images and return the link of the images (20 images is enough i think) Is there any API or modules i can use? https://developers.google.com/image-search/v1/jsondevguide http://docs.python.org/library/json.html http://docs.python.org/library/urllib2.html Cheers, Chris thanks a lot but it say it's deprecated, is there a replacement? Anyway it'll useful for me to study json, thanks :) Nico -- http://mail.python.org/mailman/listinfo/python-list
Re: Distributing methods of a class across multiple files
On Tue, 24 Jan 2012 19:54:24 -0800, lh wrote: Is this possible please? I have done some searching but it is hard to narrow down Google searches to this question. What I would like to do is, for example: 1) define a class Foo in file test.py... give it some methods 2) define a file test2.py which contains a set of methods that are methods of class Foo defined in test.py. Technically, yes, this is possible, but you shouldn't need to do it. Needing to split a single class across multiple files is a sign of bad design. If the class is that huge, then it probably does too many things and should be broken up into multiple classes and then reassembled using composition. [...] In short I would like to distribute code for one class across multiple files so a given file doesn't get ridiculously long. What do you call ridiculously long? One of the largest modules in the Python standard library is decimal. I consider decimal to be about as big as a single module should get: over 5000 lines of code. Any larger, and you should consider splitting it into a package with multiple files. But note that those 5000 lines include over 500 lines of comments, details documentation, plenty of blank lines, 14 public classes, 3 public functions, and at least 17 private functions or classes. The main class, decimal.Decimal, is about 2800 lines of code. If your class is smaller than that, I don't think you need to worry about splitting it. But let's suppose you really do have a good reason to split the class into multiple files. And not just because that's how I'd do it in Java. Suppose you have a class Spam, and it has two methods, spam() and eggs(). You want to split the methods into different files. (Perhaps you want to win a bet.) There are three main possibilities: (1) Inheritance. (2) Composition or delegation. (3) Dynamic code injection. Let's start with inheritance. In module a.py, create a class: class EggMixin: def eggs(self): c = self.colour print(%s eggs go well with %s spam % (c, c)) Notice that as a mixin, EggsMixin isn't required to provide the self.colour attribute. Technically it isn't necessary for this to be a mixin, but it is probably the best design. Now in module main.py, create the Spam class you really want, using multiple inheritance to inherit from the real superclass and the mixin: import a class Spam(SpamParent, a.EggMixin): def __init__(self, colour='green'): print(Spam spam spam LOVELY SPAM!!!) self.colour = colour def spam(self, n): return spam!*n By the way, SpamParent is optional. If you don't need it, just leave it out. Now, on to composition. First, let's redesign the egg class in a.py: class Egg: def __init__(self, owner): self.owner = owner def eggs(self): c = self.owner.colour print(%s eggs go well with %s spam % (c, c)) And in main.py: import a class Spam(object): def __init__(self, colour='green'): print(Spam spam spam LOVELY SPAM!!!) self.colour = colour # Create an Egg that has this Spam instance as the owner. egg = a.Egg(owner=self) # And store it for later use. self._egg = egg def spam(self, n): return spam!*n def eggs(self): # Delegate to the saved egg. return self._egg.eggs() Last but not least, lets try dynamic code injection. In a.py, create a function using a placeholder self parameter: def eggs(self): c = self.colour print(%s eggs go well with %s spam % (c, c)) And here is your main module: import a class Spam(object): def __init__(self, colour='green'): print(Spam spam spam LOVELY SPAM!!!) self.colour = colour def spam(self, n): return spam!*n # Add the extra method that we want. Spam.eggs = a.eggs So now you have three ways of doing something that shouldn't be done :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: unittest and threading
Let me have a guess :) On 25/01/2012 7:42 PM, Ross Boylan wrote: On Tue, 2012-01-24 at 13:54 -0800, Ross Boylan wrote: ... The code I want to test uses threads, but that is not entirely internal from the standpoint of the unit test framework. The unit test will be executing in one thread, but some of the assertions may occur in other threads. The question is whether that will work, in particular whether assertion failures will be properly captured and logged by the test framework. I think it will - so long as your test on the main thread hasn't returned yet. Concretely, a test may exercise some code that triggers a callback; the callback might come in a different thread, and the code that is triggered might make various assertions. There are two issues: whether assertions and their failures that happen in other threads will be correctly received by the test framework, and whether the framework is robust against several assertions being raised simultaneously in different threads. The latter seems a bit much to hope for. I suspect both will be fine. I assume that, at a minimum, the my test code will need to use locks or other coordination mechanisms so the test doesn't end before all code under test executes. Yep - that's the only caveat I'd expect . Finally, I'll mention two senses of threads in tests that my question does not concern, although they are also interesting. I am not concerned with testing the performance of my code, in the sense of asserting that an operation must complete before x seconds or after y seconds. Some potential implementations of such tests might use threads even if the code under test was single-threaded. The question also does not concern running lots of unit tests in parallel. nose is still worth having a look at - personally I just use it as a runner and where possible ignore its api... Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Distributing methods of a class across multiple files
lh wrote: Is this possible please? I have done some searching but it is hard to narrow down Google searches to this question. What I would like to do is, for example: 1) define a class Foo in file test.py... give it some methods 2) define a file test2.py which contains a set of methods that are methods of class Foo defined in test.py. I can import Foo obviously but it isn't clear to me how to identify the methods in test2.py to be methods of class Foo defined in test.py (normally I would just indent them def's under the class but the class isn't textually in test2.py). In short I would like to distribute code for one class across multiple files so a given file doesn't get ridiculously long. Thank you, Luke If the file is ridiculously long, could be that the class has a ridiculous number of methods. If you spread your class into multiple files, you will have a ridiculous number of tiny files with ridiculous names. My 2 cents : keep 1 class in 1 file, and keep your scopes consistent. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Algorithms in Python
The thing about algorithms is they are applicable to many programming languages (in general). Read http://en.wikipedia.org/wiki/Turing_machine On Wed, Jan 25, 2012 at 9:06 PM, Chetan Harjani chetan.harj...@gmail.com wrote: Is there any book or site on python algorithms which asks more and teaches less, I don't want to get bored, and at the same time I want to learn and act more. I use ubuntu. (just in case if its needed). #ALGORITHMS -- Chetan H Harjani IIT Delhi -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Algorithms in Python
2012/1/25 Chetan Harjani chetan.harj...@gmail.com: Is there any book or site on python algorithms which asks more and teaches less, I don't want to get bored, and at the same time I want to learn and act more. I use ubuntu. (just in case if its needed). #ALGORITHMS There is a Stanford online class on Algorithms, which will start really soon. It is stated that Python may be used for home assignments. Maybe you are not too late. http://www.algo-class.org/ Best regards, S.Nizamov -- http://mail.python.org/mailman/listinfo/python-list
CONCEPT OF GOD IN ISLAM !!!!!!!!!!!!!!!
CONCEPT OF GOD IN ISLAM Sorry for not sending anything related to this group but it might be something new to you. CONCEPT OF GOD IN ISLAM It is a known fact that every language has one or more terms that are used in reference to God and sometimes to lesser deities. This is not the case with Allah. Allah is the personal name of the One true God. Nothing else can be called Allah. The term has no plural or gender. This shows its uniqueness when compared with the word god which can be made plural, gods, or feminine, goddess. It is interesting to notice that Allah is the personal name of God in Aramaic, the language of Jesus and a sister language of Arabic. The One true God is a reflection of the unique concept that Islam associates with God. To a Muslim, Allah is the Almighty, Creator and Sustainer of the universe, Who is similar to nothing and nothing is comparable to Him. The Prophet Muhammad was asked by his contemporaries about Allah; the answer came directly from God Himself in the form of a short chapter of the Quran, which is considered the essence of the unity or the motto of monotheism. This is chapter 112 which reads: In the name of God, the Merciful, the Compassionate. Say (O Muhammad) He is God the One God, the Everlasting Refuge, who has not begotten, nor has been begotten, and equal to Him is not anyone. Some non Muslims allege that God in Islam is a stern and cruel God who demands to be obeyed fully. He is not loving and kind. Nothing can be farther from truth than this allegation. It is enough to know that, with the exception of one, each of the 114 chapters of the Quran begins with the verse: In the name of God, the Merciful, the Compassionate. In one of the sayings of Prophet Muhammad (PBUH) we are told that God is more loving and kinder than a mother to her dear child. But God is also Just. Hence evildoers and sinners must have their share of punishment and the virtuous, His bounties and favors. Actually God’s attribute of Mercy has full manifestation in His attribute of Justice. People suffering throughout their lives for His sake and people oppressing and exploiting other people all their lives should not receive similar treatment from their Lord. Expecting similar treatment for them will amount to negating the very belief in the accountability of man in the Hereafter and thereby negating all the incentives for a moral and virtuous life in this world. The following Quranic verses are very clear and straightforward in this respect: Verily, for the Righteous are gardens of Delight, in the Presence of their Lord. Shall We then treat the people of Faith like the people of Sin? What is the matter with you? How judge you? (68:34-36) Islam rejects characterizing God in any human form or depicting Him as favoring certain individuals or nations on the basis of wealth, power or race. He created the human beings as equals. They may distinguish themselves and get His favor through virtue and piety only. The concept that God rested in the seventh day of creation, that God wrestled with one of His soldiers, that God is an envious plotter against mankind, or that God is incarnate in any human being are considered blasphemy from the Islamic point of view. The unique usage of Allah as a personal name of God is a reflection of Islam’s emphasis on the purity of the belief in God which is the essence of the message of all God’s messengers. Because of this, Islam considers associating any deity or personality with God as a deadly sin which God will never forgive, despite the fact He may forgive all other sins. The Creator must be of a different nature from the things created because if he is of the same nature as they are, he will be temporal and will therefore need a maker. It follows that nothing is like Him. If the maker is not temporal, then he must be eternal. But if he is eternal, he cannot be caused, and if nothing outside him causes him to continue to exist, which means that he must be Self-Sufficient. And if He does not depend on anything for the continuance of His own existence, then this existence can have no end. The Creator is therefore eternal and everlasting: ‘He is the First and the Last.’ He is Self-Sufficient or Self-Subsistent or, to use a Quranic term, Al- Qayyum. The Creator does not create only in the sense of bringing things into being, He also preserves them and takes them out of existence and is the ultimate cause of whatever happens to them. God is the Creator of everything. He is the guardian over everything. Unto Him belong the keys of the heavens and the earth. (39:62, 63) No creature is there crawling on the earth, but its provision rests on God. He knows its lodging place and its repository. (11:6) GOD’S ATTRIBUTES If the Creator is Eternal and Everlasting, then His attributes must also be eternal and everlasting. He should not lose any of His attributes nor acquire new ones. If this is so, then His attributes are absolute. Can there be more than one Creator with such
Re: Algorithms in Python
I assume you have seen this book? http://www.apress.com/9781430232377 Thijs On Wed, Jan 25, 2012, at 15:36, Chetan Harjani wrote: Is there any book or site on python algorithms which asks more and teaches less, I don't want to get bored, and at the same time I want to learn and act more. I use ubuntu. (just in case if its needed). #ALGORITHMS -- Chetan H Harjani IIT Delhi -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
looking for good tutorials/books for advanced beginners
Hi, a few month ago I began to learn Python. I have read and understood the following tutorials so far: http://docs.python.org/py3k/tutorial/index.html http://docs.python.org/release/3.2/howto/functional.html http://docs.python.org/release/3.2/howto/doanddont.html http://docs.python.org/release/3.2/howto/logging.html http://www.python.org/dev/peps/pep-0008/ From a pracitcal perspective I solved 62 of the easier problems from http://projecteuler.net and coded some mini programs: - small prisoners dilemma tournament: different strategies compete (forgiving tit for tat wins of course in the end ;)) (P3) - http://daiw.de/BlogFiles/PrisonersDilemma.py - a short simulation of the lorenz waterwheel with turtle output of the phase space trajectory (P3) - http://daiw.de/BlogFiles/LorenzWaterwheel.py - a simple neural network (MLP), that trains with backpropagation and can be plottet (again with the turtle :D) (P3) - http://daiw.de/BlogFiles/NeuralNetwork.py - Conway's Game of Life with OpenCV (P2) - http://daiw.de/BlogFiles/GoL.py - some parsers for different log files with graphical output using MatPlotLib (P2) I am not planning to do bigger projects at the moment, but I would love to learn more about Python because I like it and I have fun with it. I guess that especially in OOP stuff I still think to much in C++ style, because that's where I come from. What tutorials/books can you recomment to me based on my current experience? Something with the difficulty level of Effecive C++ but just for Python could fit. I linked my source codes, because perhaps they give directly on the first glance a hint where my biggest weaknesses are and what I should learn next. Regards Dobi -- http://mail.python.org/mailman/listinfo/python-list
Re: Algorithms in Python
There is this book (it´s free ebook) http://www.brpreiss.com/books/opus7/html/book.html , you can also check this list: http://programming-motherfucker.com/become.html#Python or if you want something more official then there is official wiki page: http://wiki.python.org/moin/PythonBooks ... 2012/1/25 Chetan Harjani chetan.harj...@gmail.com Is there any book or site on python algorithms which asks more and teaches less, I don't want to get bored, and at the same time I want to learn and act more. I use ubuntu. (just in case if its needed). #ALGORITHMS -- Chetan H Harjani IIT Delhi -- http://mail.python.org/mailman/listinfo/python-list -- PGP pub key: http://keyserver.pgp.com/vkd/SubmitSearch.event?SearchCriteria=visgean%40gmail.com http://www.abclinuxu.cz/lide/visgean/gpg A453 B7F3 33D9 3BE6 2B8A | F014 5347 EBAC 0A5A 3E92 Jabber: visg...@jabber.org | visg...@jabber.cz Github: http://github.com/Visgean -- http://mail.python.org/mailman/listinfo/python-list
Re: Distributing methods of a class across multiple files
First, thanks for all the thoughtful replies. I am grateful. Second, I figured I'd get a lot of judgement about how I really shouldn't be doing this. Should have pre-empted it :-) oh well. There is a place IMHO for filename as another structuring element to help humans in search. Also it can be convenient to have two people who are working on methods for one class that have different directions to have different files (even if modern tools can handle distinct edits on the same file by multiple folks). Third, length. Well 5000 lines eh... I'm nowhere near that guess I can stick with one file. Steven thanks especially for your thorough reply about alternatives. Again I really appreciate the quality replies made here. very impressed. I had not thought of the mixin approach in particular. I was just hoping there was something like extend class Foo I could put at the top of the file and then keep writing methods indented below it. But I will think about some of these alternatives... Humbly, Luke -- http://mail.python.org/mailman/listinfo/python-list
Re: Distributing methods of a class across multiple files
On 2012-01-25, lh lhughe...@gmail.com wrote: First, thanks for all the thoughtful replies. I am grateful. Second, I figured I'd get a lot of judgement about how I really shouldn't be doing this. Should have pre-empted it :-) oh well. There is a place IMHO for filename as another structuring element to help humans in search. Also it can be convenient to have two people who are working on methods for one class that have different directions to have different files (even if modern tools can handle distinct edits on the same file by multiple folks). Of the three solutions Steven presented, the latter two leave very strong coupling between the code in your separate files. This makes working with the files independently impractical. Stick with mixin classes and pay heed to the Law of Demeter if you want to de-couple them enough to work on independently. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Determining version of OpenSSL linked against python?
Hi Is this possible at all? Cheers Adam On Mon, Jan 23, 2012 at 14:01, Adam Mercer ramer...@gmail.com wrote: Hi I'm trying to write a script that determines the version of OpenSSL that python is linked against, using python-2.7 this is easy as I can use: import ssl ssl.OPENSSL_VERSION but unfortunately I need to support python-2.6, from an older script I used the following: import _ssl ssl_lib = _ssl.__file__ to get the path to the _ssl.so module and then I parsed the output of ldd (on linux) to get the path to the OpenSSL library and then parsed the version from the filename. In other words it's very messy. I had a little success using this approach but I have recently received a bug report that this doesn't seem to work on Debian Squeeze. When I try to query the __file__ attribute of the _ssl module I get the following error: import _ssl _ssl.__file__ Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute '__file__' Can anyone offer any suggestions as to what is going wrong with the above code or offer an alternative way of determining the OpenSSl version using python-2.6? Cheers Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: search google with python
On Wed, Jan 25, 2012 at 5:36 AM, Tracubik affdfsdfds...@b.com wrote: thanks a lot but it say it's deprecated, is there a replacement? Anyway it'll useful for me to study json, thanks :) I don't believe Google is particularly supportive of allowing third-parties (like us) to use their search infrastructure. All of the search-related APIs they used to provide are slowly going away and not being replaced, as far as I can tell. If you just need to search images (and not Google Image Search in particular), Bing's API appears to be supported and not about to go away. ( http://msdn.microsoft.com/en-us/library/dd900818.aspx ) You could, in theory, make requests to Google just like a web browser and parse the resulting HTML, but that tends to be fragile and prone to break. I believe it also violates Google's Terms of Service. -- Jerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Algorithms in Python
Thanks Alec for the link. U know I wanted to read this book by Simon Singh - The Code Book, I hear its good. Thanks Nizamov for the link, I am really looking forward to join the class, and since its free, it is totally an asset. Yes Thijs I have seen this book, and since its such a big book, I am avoiding it right now but I really liked the author's style when I read his book on python language. Thanks Visgean, the links seem really valuable Thanking all with regards Chetan H Harjani IIT Delhi -- http://mail.python.org/mailman/listinfo/python-list
Find the mime type of a file.
I want to have a list of all the images in a directory. To do so I want to have a function that find the mime type of a file. I have found mimetypes.guess_type but it only works by examining the extension. In GNU/Linux the file utility do much better by actually looking at the file. Is there an equivalent function in python (as a last resort I can always use the external file utility). Olive -- http://mail.python.org/mailman/listinfo/python-list
Re: Is a with on open always necessary?
On 1/20/12 07:44 , Andrea Crotti wrote: I normally didn't bother too much when reading from files, and for example I always did a content = open(filename).readlines() But now I have the doubt that it's not a good idea, does the file handler stays open until the interpreter quits? So maybe doing a with open(filename) as f: contents = f.readlines() is always a better idea?? It's a better idea when possible. Sometimes the descriptor is opened in one method and closed in another. In that case, with isn't possible. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Is a with on open always necessary?
On 1/21/12 03:38 , Lie Ryan wrote: It is only strictly necessary for programs that opens thousands of files in a short while, since the operating system may limit of the number of active file handlers you can have. The number you're looking for is 20 on many unix systems. That's all. 20 concurrently open file descriptors. Modern systems open that number up somewhat, or make it tailorable. But the number is still much lower than you might expect. --rich -- http://mail.python.org/mailman/listinfo/python-list
PyWart: Python regular expression syntax is not intuitive.
In particular i find the extension notation syntax to be woefully
inadequate. You should be able to infer the action of the extension
syntax intuitively, simply from looking at its signature. I find
myself continually needing to consult the docs because of the lacking
or misleading style of the current syntax. Consider:
(...) # Group Capture
Okay here. Parenthesis feel very natural for delimiting a group.
(?...) # Base Extension Syntax
All extensions are wrapped in parenthesis and start with a question
mark, but i believe the question mark was a very bad choice, since the
question mark is already specific to zero or one repetitions of
preceding RE. This simple error is why i believe Python re's are so
damn difficult to eyeball parse. You'll constantly be forced to spend
too much time deciding if this question mark is a referring to
repeats, or is the start of an extension syntax. We should have
choosen another char, and the char should NOT be known to RE in any
other place. Maybe the tilde would work? Wait, i have a MUCH better
idea!!!
Actually the best choice would have been using BRACES instead of
PARENTHESIS to delimit the extension syntax, since parenthesis are
used (wisely i might add!) for group captures. Also, anything
contained in braces is more likely to be understood (by almost all
programmers) as a command block -- unfortunately some idiot decided
to use braces for specifying ranges! WHAT A F'ING WASTE of intuitive
chars!
(?iLmsux) # Passing Flags Internally
This is ridiculous. re's are cryptic enough without inviting TIMTOWDI
over to play. Passing flags this way does nothing BUT harm
readability. Please people, pass your flags as an argument to the
appropriate re.method() and NOT as another cryptic syntax.
(?:...) # Non-Capturing Group
When i look at this pattern non-capturing DOES NOT scream out at me,
and again, the question mark is used incorrectly. When i think of a
char that screams NEGATIVE, i think of the exclamation mark, NOT the
question mark. And how the HELL is the colon helping me to interpret
this syntax?
(?Pname...) # Named Group Capture
(?P=name) # Named Group Reference
(?#...) # Comment
## The following assertions are highly flawed ##
(?=...) # positive look ahead
(?!...) # negative look ahead
(?=...) # positive look behind
(?!...) # negative look behind
I cannot decipher these patterns in their current syntactical forms.
Too much information is missing or misleading. I have no idea which
pattern is looking forward, which pattern is looking backward, which
is pattern negative, and which pattern is positive. I need syntactical
clues! Consider these:
(?=...) #Read as forward equals pattern?
(?!=...) #Read as forward NOT equals pattern?
(?=...) #Read as backwards equals pattern?
(?!=...) #Read as backwards NOT equals pattern?
However, i really don't like the fact that negative assertions need
one extra char than positive assertions. Here is an alternative:
(?+...) #Read as forward equals pattern?
(?-...) #Read as forward NOT equals pattern?
(?+...) #Read as backwards equals pattern?
(?-...) #Read as backwards NOT equals pattern?
Looks much better HOWEVER we still have too much useless noise.
Replace the parenthesis delimiters with braces, and drop the where's
waldo question mark, and we have a simplistically intuitive
syntactical bliss!
{...} # Base Extension Syntax
{iLmsux} # Passing Flags Internally
{!()...} or (!...) # Non Capturing.
{NG=identifier...} # Named Group Capture
{NG.name} # Named Group Reference
{#...} # Comment
{+...} # Positive Look Ahead Assertion
{-...} # Negative Look Ahead Assertion
{+...} # Positive Look Behind Assertion
{-...} # Positive Look Behind Assertion
{(id/name)yes-pat|no-pat}
*school-bell-rings*
PS: In my eyes, Python 3000 is already a dinosaur.
--
http://mail.python.org/mailman/listinfo/python-list
Where to put data
I'm having a disagreement with a buddy on the packaging of a program we're doing in Python. It's got a number of modules and large number of library files. The library stuff is data, not code. I'd like to put the modules in /usr/lib/pythonX.Y/mymodules or wherever setup.py decides. And the data in /usr/share/lib/myprogram. My buddy says, that it'll be hard to be consistant in the /usr/share/.. when we consider platforms other than linux. So, he wants: /usr/lib/pythonX.Y/myprogram mymodules ... mydata I've got 2 issues with this: 1. I don't know if putting data in the python tree is legit. 2. I'd have to do a lot of rewritting. My modules currently use: include mymodules.foobar x=mymodules.foobar.func() and I would need to change that to: include myprogram.mymodules.foobar x=myprogram.mymodules.foobar.func() unless there is python way to drop the myprogram bit? -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On 1/23/12 21:57 , Rick Johnson wrote: Here is a grep from the month of September 2011 showing the rampantly egregious misuse of the following words and phrases: * pretty * hard * right * used to * supposed to Pretty is the most ludicrous of them all! As you will see, pretty is used superfluously, over and over again! In fact, you could safely omit pretty without sacrificing any meaning of most all the sentences that include the word pretty. Likewise, in 99% of the examples, the word difficult can be substituted for the word hard without sacrificing any meaning. Same for correct and right. Of course, used to and supposed to will require people to rethink there lazy and slothful ways. I disagree on all points. Pretty means mostly. The difference in meaning is significant. I'm sure is definitive. I'm pretty sure leaves room for variation. My dictionary lists arduous as the second, (of 17), definitions for hard. etc. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Jan 25, 11:16 am, Rick Johnson rantingrickjohn...@gmail.com
wrote:
{!()...} or (!...) # Non Capturing.
Yuck: on second thought, i don't like {!()...}, mainly because non-
capturing groups should use the parenthesis delimiters to keep the API
consistent. Try this instead -- (!:...)
{NG=identifier...} # Named Group Capture
{NG.name} # Named Group Reference
...should be {NG.identifier}. I am also feeling like named group
syntax could be more simplistic without sacrificing readability.
{=identifier...} # Named Group Capture
{.identifier} # Named Group Reference
--
http://mail.python.org/mailman/listinfo/python-list
Re: Find the mime type of a file.
On Wed, Jan 25, 2012 at 9:04 AM, Olive di...@bigfoot.com wrote: I want to have a list of all the images in a directory. To do so I want to have a function that find the mime type of a file. I have found mimetypes.guess_type but it only works by examining the extension. In GNU/Linux the file utility do much better by actually looking at the file. Is there an equivalent function in python (as a last resort I can always use the external file utility). There's 3rd-party Python bindings for the library that underlies the `file` command: https://github.com/ahupp/python-magic And there's an unrelated pure(?) Python standalone module from A-A-P: http://www.a-a-p.org/exec/ref-filetype.html Tip: google file type detection python Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: What happened tp scipy.stsci?
I found it it is in the stsci package. On Jan 24, 11:36 am, Eelco hoogendoorn.ee...@gmail.com wrote: Either way, if I understand correctly, what you are trying to do could be done with numpy.median(imagestack, axis=stackaxis), no? Yes, I guess so. I didn't realize numpy.median had an axis option. Thanks. That's one less import. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is a with on open always necessary?
On 01/26/2012 04:17 AM, K Richard Pixley wrote: On 1/21/12 03:38 , Lie Ryan wrote: It is only strictly necessary for programs that opens thousands of files in a short while, since the operating system may limit of the number of active file handlers you can have. The number you're looking for is 20 on many unix systems. That's all. 20 concurrently open file descriptors. Modern systems open that number up somewhat, or make it tailorable. But the number is still much lower than you might expect. From what I can gather, Linux defaults to 1024, Windows 16384, and OSX 256; I doubt many people would need to work with other OSes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Where to put data
On Jan 25, 11:26 am, bvdp b...@mellowood.ca wrote: I've got 2 issues with this: 1. I don't know if putting data in the python tree is legit. 2. I'd have to do a lot of rewritting. My modules currently use: I would not put anything in the toplevel Python folder. You need to place everything under site-packages -- Python27\Lib\site-packages \PackageName\blah. Of course client created files should be saved to a more accessible place. [...] unless there is python way to drop the myprogram bit? Considering mymodules is a valid python package, you can do: py from mymodules import foobar -- http://mail.python.org/mailman/listinfo/python-list
Getting an embedded Python runtime to use the current active virtualenv
Hi all, I've had this question up on Stackoverflow for a while but no one has yet come along with an authoritative answer. I've written some C code that interfaces with a Python package through an embedded Python runtime. All of it works pretty well except that now I want the embedded runtime to use a virtualenv. The workflow that I'm used to with virtualenvs starts with source activate but, AFAICT, all that does is set the $PATH to prefer a special executable; it doesn't do anything special to other environment variables. I could be missing something here, but trying to discover the appropriate $PYTHONHOME and $PYTHONPATH from the $PATH and then feed them to the embedded runtime seems like a kludge at best. I'm guess that there has to be a *right* way to do this. Could somebody give me a clue? Thanks! ~Brian PS - If you want some rep: http://stackoverflow.com/questions/7492855/getting-an-embedded-python-runtime-to-use-the-current-active-virtualenv -- http://mail.python.org/mailman/listinfo/python-list
Re: Where to put data
I would just like to make a strong plea that you make it possible to install in places other than /usr. Bascially, 'python setup.py install --prefix /some/alternative/place' should work. Evan On 01/25/2012 11:26 AM, bvdp wrote: I'm having a disagreement with a buddy on the packaging of a program we're doing in Python. It's got a number of modules and large number of library files. The library stuff is data, not code. I'd like to put the modules in /usr/lib/pythonX.Y/mymodules or wherever setup.py decides. And the data in /usr/share/lib/myprogram. My buddy says, that it'll be hard to be consistant in the /usr/share/.. when we consider platforms other than linux. So, he wants: /usr/lib/pythonX.Y/myprogram mymodules ... mydata I've got 2 issues with this: 1. I don't know if putting data in the python tree is legit. 2. I'd have to do a lot of rewritting. My modules currently use: include mymodules.foobar x=mymodules.foobar.func() and I would need to change that to: include myprogram.mymodules.foobar x=myprogram.mymodules.foobar.func() unless there is python way to drop the myprogram bit? -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
Rick Johnson rantingrickjohn...@gmail.com wrote: (?...) # Base Extension Syntax All extensions are wrapped in parenthesis and start with a question mark, but i believe the question mark was a very bad choice, since the question mark is already specific to zero or one repetitions of preceding RE. This simple error is why i believe Python re's are so damn difficult to eyeball parse. You'll constantly be forced to spend too much time deciding if this question mark is a referring to repeats, or is the start of an extension syntax. We should have choosen another char, and the char should NOT be known to RE in any other place. Maybe the tilde would work? Wait, i have a MUCH better idea!!! The problem with your idea is that it breaks compatability with other non- Python regular expression engines. Python didn't invent the (?...) syntax, it originated with Perl. Try complaining to a Perl group instead. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Jobs for developers
On 24/01/2012 19:02, Rima Al-Sheikh wrote: Hi There, We are looking to hire talented developers to join different teams.. Please use the job board rather than spamming the mailing list: http://www.python.org/community/jobs/ cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On 25/01/2012 05:55, Michael Torrie wrote: On 01/24/2012 10:49 PM, Michael Torrie wrote: On 01/24/2012 05:43 PM, Rick Johnson wrote: Actually my custom script had a small flaw which kept it from capturing ALL the atrocities. Here is a run with the bugfixes: Wow. I had to trim 80% of your e-mail just to get rid of old quoted posts. For an expert, Rick, I'm really surprised you don't bother to trim your posts. Even experts make mistakes, I guess. I, not being an expert, make many mistakes of course. I neglected to notice that the pages and pages of off-topic, quoted material was in fact the output of your program. (Looked like line-noise at first blush.) My mistake in leveling a baseless accusation. I see that he fixed the flaw, but not the spelling... -- http://mail.python.org/mailman/listinfo/python-list
Current Web URL
Hi All,
I have been breaking my brains to find a solution to determining what
the current URL is in a web browser navigation bar.
It cannot be a prefixed values since I will not know what platform it is
running from at the time it is opened by the users.
Can this URL be extracted from the navigation bar so it can be parsed?
I tried this response =
urllib2.urlopen('http://www.google.com').geturl() however it seems to
always to give me the google url and not the one in the navigation bar.
Any Suggestions Please?
Respectfully,
William Abdo
This email message is intended for the use of the person to whom it has been
sent, and may contain information that is confidential or legally protected. If
you are not the intended recipient or have received this message in error, you
are not authorized to copy, distribute, or otherwise use this message or its
attachments. Please notify the sender immediately by return e-mail and
permanently delete this message and any attachments. Verio, Inc. makes no
warranty that this email is error or virus free. Thank you.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Determining version of OpenSSL linked against python?
On 1/25/2012 11:02 AM, Adam Mercer wrote: Is this possible at all? If you are not willing to tell Debian Squeeze users to install 2.7, or that they cannot run your program, ask the bug reporter to tell you what version of OpenSSL the system comes with and code it into your program. Or possibly, depending on what you do with the version info and what the differences are between versions, replace 'if version ...' constructs with 'try ... except...' constructs. On Mon, Jan 23, 2012 at 14:01, Adam Mercerramer...@gmail.com wrote: Hi I'm trying to write a script that determines the version of OpenSSL that python is linked against, using python-2.7 this is easy as I can use: import ssl ssl.OPENSSL_VERSION but unfortunately I need to support python-2.6, from an older script I used the following: import _ssl ssl_lib = _ssl.__file__ to get the path to the _ssl.so module and then I parsed the output of ldd (on linux) to get the path to the OpenSSL library and then parsed the version from the filename. In other words it's very messy. I had a little success using this approach but I have recently received a bug report that this doesn't seem to work on Debian Squeeze. When I try to query the __file__ attribute of the _ssl module I get the following error: import _ssl _ssl.__file__ Traceback (most recent call last): File stdin, line 1, inmodule AttributeError: 'module' object has no attribute '__file__' Can anyone offer any suggestions as to what is going wrong with the above code or offer an alternative way of determining the OpenSSl version using python-2.6? -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
ANN: pyftpdlib 0.7.0 released
Hi,
I'm pleased to announce release 0.7.0 of Python FTP Server library (pyftpdlib).
http://code.google.com/p/pyftpdlib/
=== About ===
Python FTP server library provides an high-level portable interface to
easily write asynchronous FTP/S servers with Python. pyftpdlib is
currently the most complete RFC-959 FTP server implementation
available for Python programming language.
=== sendfile() ===
sendfile(2) system call usage has finally been introduced. sendfile(2)
provides a zero-copy way of copying data from one file descriptor to
another (a socket). The phrase zero-copy refers to the fact that all
of the copying of data between the two descriptors is done entirely by
the kernel, with no copying of data into userspace buffers, resuting
in file transfers (RETR, hence from server to client) being from 2x to
3x faster.
A simple benchmark:
pyftpdlib 0.6.0:693.41 MB/sec
pyftpdlib 0.7.0: 1694.14 MB/sec
proftpd 1.3.4rc2: 1313.77 MB/sec
vsftpd 2.3.2: 1505.18 MB/sec
In order to use sendfile(2) you'll have to install pysendfile module
first (UNIX only):
http://code.google.com/p/pysendfile/
=== Faster scheduler ===
The internal scheduler, governed by CallLater and CallEvery classes,
has been rewritten from scratch and it is an order of magnitue faster,
especially for operations like cancel() which are involved when
clients are disconnected (hence invoked very often). Some benchmarks:
schedule: +0.5x
reschedule: +1.7x
cancel: +477x (with 1 milion scheduled functions)
run: +8x
Also, a single scheduled function now consumes 1/3 of the memory
thanks to __slots__ usage.
For further details see: http://code.google.com/p/pyftpdlib/issues/detail?id=189
=== SITE CHMOD ===
This new version supports SITE CHMOD command, meaning the client is
now able to change file mode bits by issuing SITE CHMOD path mode
command. The authorizer now accepts a new M permission bit, which,
when specified, enables SITE CHMOD usage:
authorizer = DummyAuthorizer()
authorizer.add_user('user', 'password', '/home/user', perm='elradfmwM')
=== Other improvements ===
* on_failed_login() callback: this is called when user provides wrong
credentials.
* CallEvery class: same as CallLater, but keeps calling a function
every X seconds.
* A benchmark script:
http://code.google.com/p/pyftpdlib/source/browse/trunk/test/bench.py
* Anti flood demo script:
http://pyftpdlib.googlecode.com/svn/trunk/demo/anti_flood_ftpd.py
A complete list of changes including enhancements and bug fixes is
available here:
http://code.google.com/p/pyftpdlib/wiki/ReleaseNotes07
=== More links ===
* Source tarball: http://pyftpdlib.googlecode.com/files/pyftpdlib-0.7.0.tar.gz
* Online docs: http://code.google.com/p/pyftpdlib/wiki/Tutorial
* FAQs: http://code.google.com/p/pyftpdlib/wiki/FAQ
* RFCs compliance paper: http://code.google.com/p/pyftpdlib/wiki/RFCsCompliance
* Issue tracker: http://code.google.com/p/pyftpdlib/issues/list
If you think pyftpdlib is worth a donation you can do so by going here:
http://code.google.com/p/pyftpdlib/wiki/Donate
Thanks,
--- Giampaolo Rodola'
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
http://code.google.com/p/pysendfile/
--
http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, Jan 25, 2012 at 10:16 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
(?...) # Base Extension Syntax
All extensions are wrapped in parenthesis and start with a question
mark, but i believe the question mark was a very bad choice, since the
question mark is already specific to zero or one repetitions of
preceding RE. This simple error is why i believe Python re's are so
damn difficult to eyeball parse. You'll constantly be forced to spend
too much time deciding if this question mark is a referring to
repeats, or is the start of an extension syntax. We should have
choosen another char, and the char should NOT be known to RE in any
other place. Maybe the tilde would work? Wait, i have a MUCH better
idea!!!
Did you read the very first sentence of the re module documentation?
This module provides regular expression matching operations *similar
to those found in Perl* (my emphasis). The goal here is
compatibility with existing RE syntaxes, not readability. Perl uses
the (?...) syntax, so the re module does too.
(?iLmsux) # Passing Flags Internally
This is ridiculous. re's are cryptic enough without inviting TIMTOWDI
over to play. Passing flags this way does nothing BUT harm
readability. Please people, pass your flags as an argument to the
appropriate re.method() and NOT as another cryptic syntax.
1) Not all regular expressions are hard-coded. Some applications even
allow users to supply regular expressions as data. Permitting flags
in the regular expression allows the user to specify or override the
defaults set by the application.
2) Permitting flags in the regular expression allows different
combinations of flags to be in effect for different parts of complex
regular expressions. You can't do that just by passing in the flags
as an argument.
(?:...) # Non-Capturing Group
When i look at this pattern non-capturing DOES NOT scream out at me,
and again, the question mark is used incorrectly. When i think of a
char that screams NEGATIVE, i think of the exclamation mark, NOT the
question mark. And how the HELL is the colon helping me to interpret
this syntax?
Don't ask us. Ask Larry Wall.
(?=...) # positive look ahead
(?!...) # negative look ahead
(?=...) # positive look behind
(?!...) # negative look behind
I cannot decipher these patterns in their current syntactical forms.
Too much information is missing or misleading. I have no idea which
pattern is looking forward, which pattern is looking backward, which
is pattern negative, and which pattern is positive. I need syntactical
clues! Consider these:
(?=...) #Read as forward equals pattern?
(?!=...) #Read as forward NOT equals pattern?
(?=...) #Read as backwards equals pattern?
(?!=...) #Read as backwards NOT equals pattern?
However, i really don't like the fact that negative assertions need
one extra char than positive assertions. Here is an alternative:
(?+...) #Read as forward equals pattern?
(?-...) #Read as forward NOT equals pattern?
(?+...) #Read as backwards equals pattern?
(?-...) #Read as backwards NOT equals pattern?
Looks much better HOWEVER we still have too much useless noise.
Replace the parenthesis delimiters with braces, and drop the where's
waldo question mark, and we have a simplistically intuitive
syntactical bliss!
Once again, these come from Perl. Note also that Perl already has
(?...) which means something entirely different.
{...} # Base Extension Syntax
{iLmsux} # Passing Flags Internally
{!()...} or (!...) # Non Capturing.
{NG=identifier...} # Named Group Capture
{NG.name} # Named Group Reference
{#...} # Comment
{+...} # Positive Look Ahead Assertion
{-...} # Negative Look Ahead Assertion
{+...} # Positive Look Behind Assertion
{-...} # Positive Look Behind Assertion
{(id/name)yes-pat|no-pat}
*school-bell-rings*
Regular expression reform is not necessarily a bad thing, but this is
just forcing everybody to learn Yet Another Regex Syntax for no real
purpose. All that you've changed here is window dressing. For an
overview of many of the *real* problems with regular expression
syntax, see
http://www.perl.com/pub/2002/06/04/apo5.html
Ian
--
http://mail.python.org/mailman/listinfo/python-list
Re: search google with python
On 1/25/2012 8:38 AM, Jerry Hill wrote: On Wed, Jan 25, 2012 at 5:36 AM, Tracubikaffdfsdfds...@b.com wrote: thanks a lot but it say it's deprecated, is there a replacement? Anyway it'll useful for me to study json, thanks :) I don't believe Google is particularly supportive of allowing third-parties (like us) to use their search infrastructure. All of the search-related APIs they used to provide are slowly going away and not being replaced, as far as I can tell. True. The Google SOAP API disappeared years ago. The AJAX search widget was very restrictive, and is now on end of life (no new users). Google Custom Search only lets you search specific sites. The Bing API comes with limitations on what you can do with the results. The Yahoo search API went away, replaced by the Yahoo BOSS API. Then that was replaced by a pay-per-search interface. Bleeko has an API, but you have to ask to use it. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Jan 25, 11:26 am, K Richard Pixley r...@noir.com wrote: I disagree on all points. Pretty means mostly. The difference in meaning is significant. I'm sure is definitive. I'm pretty sure leaves room for variation. But pretty does not translate well as a quantifier, even though that's exactly what you are doing when you use pretty to QUANTIFY another word. Let's look at all the improper uses of pretty as a quantifier in the month of September 2011... py lst = re.findall(r'pretty \w+', s, re.I) py lst.__len__() 71 py set(lst) set(['pretty cool', 'pretty quick', 'pretty nasty', 'Pretty easy', 'pretty useless', 'pretty logical', 'pretty rare', 'pretty sure', 'pretty straight', 'pretty optimistic', 'pretty unimportant', 'pretty easy', 'pretty damn', 'Pretty much', 'pretty obvious', 'Pretty fast', 'pretty be', 'pretty good', 'pretty off', 'pretty inefficient', 'pretty bizarre', 'pretty minimal', 'pretty much', 'pretty cleanly', 'pretty natural', 'pretty mean', 'pretty acceptable', 'Pretty immaterial', 'pretty common', 'pretty well']) Wow, why i am not surprised! Let's pick one usage at random and try to understand it. I think XYZ is pretty easy. You don't even need pretty to get your point across. You could simply say I think XYZ is easy. Furthermore, if you insist on QUANTIFYING a QUANTIFIER, simply use any number of legal QUANTIFIERS. I think XYZ is VERY easy or I think XYZ is SOMEWHAT easy or I think XYZ is difficult. Let's see which combination is most pervasive in this group: py d = dict([(lst.count(x),x) for x in setlst]) py d[max(d)] 'pretty much' So i suppose that pretty much sums it up folks. My dictionary lists arduous as the second, (of 17), definitions for hard. Again, like pretty, this usage is a perversion of the word hard. Hard should ONLY be used to describe the tangible properties of a physical object. You CANNOT use a tangible word to describe an intangible action; like work, or task. Work can be difficult, and tasks can be difficult, but there is NO way in heaven or earth that work can be hard, or soft, or squishy. Maybe an object you are working ON can be hard, soft, or squishy -- but work, no way. You are short circuiting intelligence when you use words in this manner. In the general sense, I take no issue with words that carry more than one meaning when used in different contexts. I DO however take issue when words are used superfluously, or in a manner that is non intelligent, or when people choose to use misleading words simply because those words have less syllable than the proper word. PS: Just like i suspected; not one single use of pretty was wielded to describe the pleasurable attributes of a person, place, or thing. Mind boggling! -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On 1/25/2012 12:16 PM, Rick Johnson wrote: (?...) # Base Extension Syntax All extensions are wrapped in parenthesis and start with a question mark, but i believe the question mark was a very bad choice, since the I think that syntax came either from Perl or the pcre library used by several open source programs, including several Python versions. https://en.wikipedia.org/wiki/Pcre has some info on this. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On 2012-01-25, Rick Johnson rantingrickjohn...@gmail.com wrote: Wow, why i am not surprised! Let's pick one usage at random and try to understand it. I think XYZ is pretty easy. You don't even need pretty to get your point across. You could simply say I think XYZ is easy. Furthermore, if you insist on QUANTIFYING a QUANTIFIER, simply use any number of legal QUANTIFIERS. I think XYZ is VERY easy or I think XYZ is SOMEWHAT easy or I think XYZ is difficult. I remind you of http://orwell.ru/library/essays/politics/english/e_polit -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Determining version of OpenSSL linked against python?
On Wed, Jan 25, 2012 at 14:04, Terry Reedy tjre...@udel.edu wrote: If you are not willing to tell Debian Squeeze users to install 2.7, or that they cannot run your program, ask the bug reporter to tell you what version of OpenSSL the system comes with and code it into your program. I would like to only support python-2.7 as that would make a few other things easier but the powers that be think otherwise, I unfortunately need to target python-2.6. Or possibly, depending on what you do with the version info and what the differences are between versions, replace 'if version ...' constructs with 'try ... except...' constructs. My code already has a try... except block that tries the ssl.OPENSSL_VERSION approach first but I wanted to have a fallback method that works with python-2.6. Looks like I may need to hardcode certain things. Cheers Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Algorithms in Python
On 2012-01-25, Chetan Harjani chetan.harj...@gmail.com wrote: Thanks Alec for the link. U know I wanted to read this book by Simon Singh - The Code Book, I hear its good. It indeed is. I only remember one error, an error every Scandinavian would have spotted. His book on Fermat's theorem is even better. /Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Determining version of OpenSSL linked against python?
Adam Mercer ramer...@gmail.com wrote: On Wed, Jan 25, 2012 at 14:04, Terry Reedy tjre...@udel.edu wrote: If you are not willing to tell Debian Squeeze users to install 2.7, or that they cannot run your program, ask the bug reporter to tell you what version of OpenSSL the system comes with and code it into your program. I would like to only support python-2.7 as that would make a few other things easier but the powers that be think otherwise, I unfortunately need to target python-2.6. Or possibly, depending on what you do with the version info and what the differences are between versions, replace 'if version ...' constructs with 'try ... except...' constructs. My code already has a try... except block that tries the ssl.OPENSSL_VERSION approach first but I wanted to have a fallback method that works with python-2.6. Looks like I may need to hardcode certain things. One other possibility is to parse the output of ssh -V: , | $ ssh -V | OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010 | $ python | Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) | [GCC 4.5.2] on linux2 | Type help, copyright, credits or license for more information. | import ssl | ssl.OPENSSL_VERSION | 'OpenSSL 0.9.8o 01 Jun 2010' | ` This assumes that ssh and python would use the same version of openssl: not guaranteed, but seems like a reasonable assumption to me. Nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Current Web URL
On Wed, Jan 25, 2012 at 11:38 AM, William Abdo william.a...@verio.net wrote:
Hi All,
I have been breaking my brains to find a solution to determining what the
current URL is in a web browser navigation bar.
It cannot be a prefixed values since I will not know what platform it is
running from at the time it is opened by the users.
Can this URL be extracted from the navigation bar so it can be parsed?
I tried this “response = urllib2.urlopen('http://www.google.com').geturl()”
however it seems to always to give me the google url and not the one in the
navigation bar.
Could you clarify where the Web browser is running and where the
Python script is running in your situation?
Is the Web browser only notional (i.e. you just want to get the final
URL you would reach after requesting some given URL as if your script
were a browser)?
If no, what if there are multiple browsers or browser windows open?
Which URL bar would you want the URL from?
Cheers,
Chris
--
http://mail.python.org/mailman/listinfo/python-list
Re: Determining version of OpenSSL linked against python?
On Wed, Jan 25, 2012 at 14:56, Nick Dokos nicholas.do...@hp.com wrote: One other possibility is to parse the output of ssh -V: , | $ ssh -V | OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010 | $ python | Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) | [GCC 4.5.2] on linux2 | Type help, copyright, credits or license for more information. | import ssl | ssl.OPENSSL_VERSION | 'OpenSSL 0.9.8o 01 Jun 2010' | ` This assumes that ssh and python would use the same version of openssl: not guaranteed, but seems like a reasonable assumption to me. Hmm, I like that idea. Thanks for the suggestion. Cheers Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Jan 25, 2:17 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 10:16 AM, Rick Johnson Did you read the very first sentence of the re module documentation? This module provides regular expression matching operations *similar to those found in Perl* (my emphasis). The goal here is compatibility with existing RE syntaxes, not readability. Perl uses the (?...) syntax, so the re module does too. @Duncan and Ian: Did you not read the title of my post? :o) Python regular expression syntax is not intuitive. While i understand WHERE the syntax orientations from, that fact does not solve the problem. The syntax is not intuitive, and Python should ALWAYS be intuitive! We should always borrow ideas from anyone (even our enemies) when those ideas support our ideology. Perl style regexes are not Pythonic. They violate our philosophy in too many places. (?iLmsux) # Passing Flags Internally This is ridiculous. re's are cryptic enough without inviting TIMTOWDI over to play. Passing flags this way does nothing BUT harm readability. Please people, pass your flags as an argument to the appropriate re.method() and NOT as another cryptic syntax. 1) Not all regular expressions are hard-coded. Some applications even allow users to supply regular expressions as data. Permitting flags in the regular expression allows the user to specify or override the defaults set by the application. 2) Permitting flags in the regular expression allows different combinations of flags to be in effect for different parts of complex regular expressions. You can't do that just by passing in the flags as an argument. This is a valid argument, and i totally agree with you that we should not remove the ability to pass flags internally. However, my main point still stands strong (with a slight tweak). Please people, pass your flags as an argument to the appropriate re.method() and NOT as another cryptic syntax, UNLESS YOU HAVE NO OTHER CHOICE! Thanks for pointing this out. Regular expression reform is not necessarily a bad thing, but this is just forcing everybody to learn Yet Another Regex Syntax for no real purpose. I disagree here. Whist some people may be die-hard fans of the un-intuitive perl regex syntax, i believe many, if not exponentially MORE people would like to have a better alternative. Do i want to remove the current well established re module? No. But i would like to create a new regex module that is more pythonic. A regex module that we can be proud of. And just maybe, a regex module that sets the bar for all other regular expressions. Listen. Backwards compatibility and cross pollination is wonderful WHEN you can make it work. However, in the case of Perl regex syntax, this is not a cross pollination, this is a cross pollution. All that you've changed here is window dressing. For an overview of many of the *real* problems with regular expression syntax, see Window dressing is important Ian, if not, then shop owners would not continue to show displays in their shop windows. What does window dressing do exactly? It attracts the masses, and without the masses all merchants will eventually go out of buisness. Note: my argument HAS NOTHING to do with the number of folks programming python (or any language). The argument is focused on module sustainability in a community. Modules that are morbidly DIFFICULT to learn do not last. I know about PyParsing but i believe we have room for PyParsing and a more Pythonic take on Perl style regular expressions. I don't see why we could not keep all three. Let the people decide what is best for them. The greatest aspect of regexes is their compactness, and we should keep them compact. And in that respect regexes will always be cryptic to the neophyte. However, regexes do not have to be a scourge to the initiated. We must balance the compact and the intuitive nature of regexes. But most importantly, we must understand that these aspects of regexes are NOT mutually exclusive. -- http://mail.python.org/mailman/listinfo/python-list
Re: Determining version of OpenSSL linked against python?
Adam Mercer ramer...@gmail.com writes: Can anyone offer any suggestions as to what is going wrong with the above code or offer an alternative way of determining the OpenSSl version using python-2.6? I suppose you could use ctypes to load the library and call SSLeay() which returns the OpenSSL version number as a C long. Like this: from ctypes import * libssl = cdll.LoadLibrary(libssl.so) openssl_version = libssl.SSLeay() print %.9X % openssl_version This gives me 0009080FF which corresponds to 0.9.8o release which is what I have installed in Debian Squeeze. -- http://mail.python.org/mailman/listinfo/python-list
Re: Determining version of OpenSSL linked against python?
On Wed, Jan 25, 2012 at 15:21, Anssi Saari a...@sci.fi wrote: I suppose you could use ctypes to load the library and call SSLeay() which returns the OpenSSL version number as a C long. Like this: from ctypes import * libssl = cdll.LoadLibrary(libssl.so) openssl_version = libssl.SSLeay() print %.9X % openssl_version This gives me 0009080FF which corresponds to 0.9.8o release which is what I have installed in Debian Squeeze. Thanks, that looks useful. Cheers Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
Rick Johnson rantingrickjohn...@gmail.com wrote: On Jan 25, 2:17ÿpm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 10:16 AM, Rick Johnson Did you read the very first sentence of the re module documentation? This module provides regular expression matching operations *similar to those found in Perl* (my emphasis). ÿThe goal here is compatibility with existing RE syntaxes, not readability. ÿPerl uses the (?...) syntax, so the re module does too. @Duncan and Ian: Did you not read the title of my post? :o) Python regular expression syntax is not intuitive. While i understand WHERE the syntax orientations from, that fact does not solve the problem. The syntax is not intuitive, and Python should ALWAYS be intuitive! We should always borrow ideas from anyone (even our enemies) when those ideas support our ideology. Perl style regexes are not Pythonic. They violate our philosophy in too many places. Or we could implement de-facto standards where they exist. *plonk* -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Wed, Jan 25, 2012 at 1:14 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: Wow, why i am not surprised! Let's pick one usage at random and try to understand it. I think XYZ is pretty easy. You don't even need pretty to get your point across. You could simply say I think XYZ is easy. But easy and pretty easy mean two different things. Pretty easy is generally understood to be not quite as easy as just easy. Furthermore, if you insist on QUANTIFYING a QUANTIFIER, Easy is not a quantifier, so your talk of quantifying quantifiers makes no sense. simply use any number of legal QUANTIFIERS. I think XYZ is VERY easy or I think XYZ is SOMEWHAT easy or I think XYZ is difficult. Now, don't be ridiculous. Obviously, the One True Meaning of very is precise or particular, as in That is the very thing I was looking for. This in turn is derived from the archaic meaning true, as in the very God, which ultimately comes from Latin. You can't argue with Latin, and you can't just go around using very as an adverb. It doesn't even end in ly! In all seriousness, the idea that very and somewhat are somehow better in this context than pretty just because pretty has another meaning in other contexts is flatly ridiculous. The editors at dictionary.com disagree with you too: Usage Note The qualifying adverb pretty, meaning “fairly or moderately” has been in general use since the late 16th century. Although most common in informal speech and writing, it is far from restricted to them, and often is less stilted than alternatives such as relatively, moderately, and quite. Not that dictionary.com is the final authority on the English language, but I'll but a lot more stock in what they say than in a random internet troll. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Where to put data
Right now my program does a search for modules in all the normal places, which seems to work for windows, mac and linux. Once the modules are found I just insert that location into sys.path[0]. Which permits the modules to reside anywhere on the HDD. However, I have feeling that this isn't quite pythonic. -- http://mail.python.org/mailman/listinfo/python-list
Re: Where to put data
I would not put anything in the toplevel Python folder. You need to place everything under site-packages -- Python27\Lib\site-packages \PackageName\blah. Of course client created files should be saved to a more accessible place. Oh. Just looking at my setup (Ubunutu 11.10) and I see that /usr/lib/python2.7 doesn't have a site-packages directory. However, /usr/local/lib/python2.7 has both dist-packages and site-packages. So, my stuff should probably go into /usr/local/lib/python2.7/site-packages? Interesting (?) that these are empty dirs right now? Also, if I look at my sys.path value I see that /usr/local/lib/python2.7/dist-packages is in the path; but site-packages is not. Considering mymodules is a valid python package, you can do: py from mymodules import foobar Yes. Understand that part. And then I can just call 'foobar()'. What I was wondering is if there was a way to set something in __init__.py to shorten the calls. So, if I have: /usr/local/lib/python2.7/dist-packages/myprogram mymods __init__.py mod1.py mod2.py mylibs __init__.py Is there some magic I can put into myprogram/__init__.py which forces modules to be imported from mymods instead of myprogram/mymods? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Jan 25, 3:41 pm, Duncan Booth duncan.bo...@invalid.invalid wrote: Rick Johnson rantingrickjohn...@gmail.com wrote: On Jan 25, 2:17ÿpm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 10:16 AM, Rick Johnson Did you read the very first sentence of the re module documentation? This module provides regular expression matching operations *similar to those found in Perl* (my emphasis). ÿThe goal here is compatibility with existing RE syntaxes, not readability. ÿPerl uses the (?...) syntax, so the re module does too. @Duncan and Ian: Did you not read the title of my post? :o) Python regular expression syntax is not intuitive. While i understand WHERE the syntax orientations from, that fact does not solve the problem. The syntax is not intuitive, and Python should ALWAYS be intuitive! We should always borrow ideas from anyone (even our enemies) when those ideas support our ideology. Perl style regexes are not Pythonic. They violate our philosophy in too many places. Or we could implement de-facto standards where they exist. Are you so naive as to think that the Perl folks are even *slightly* interested in intuitive regexps? Have you written, or even read, any Perl code my friend? The *standards* are broken. Obviously they don't care, or they prefer the esoteric nature of their cryptic creation. *plonk* And good day to you. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, Jan 25, 2012 at 2:32 PM, Duncan Booth duncan.booth@invalid.invalid wrote: The problem with your idea is that it breaks compatability with other non- Python regular expression engines. Python didn't invent the (?...) syntax, it originated with Perl. Try complaining to a Perl group instead. The Perl folks didn't like it either: http://en.wikipedia.org/wiki/Perl_6_rules -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Jan 25, 3:45 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 1:14 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: Wow, why i am not surprised! Let's pick one usage at random and try to understand it. I think XYZ is pretty easy. You don't even need pretty to get your point across. You could simply say I think XYZ is easy. But easy and pretty easy mean two different things. Only to you. In my world, the pleasurable aspects of a tangible object can have no effect on my opinion of the difficulty of a task. Pretty easy is generally understood to be not quite as easy as just easy. So why not say slightly easy? Slightly can inject quantity into another word, whereas pretty cannot. Pretty has no quantity Furthermore, if you insist on QUANTIFYING a QUANTIFIER, Easy is not a quantifier, so your talk of quantifying quantifiers makes no sense. Yes, i made a mistake here when i copy pasted the text. The original phrase i referenced (in my draft) was pretty much. I must have have changed it unknowingly. simply use any number of legal QUANTIFIERS. I think XYZ is VERY easy or I think XYZ is SOMEWHAT easy or I think XYZ is difficult. Now, don't be ridiculous. Obviously, the One True Meaning of very is precise or particular, as in That is the very thing I was looking for. You don't need to quantify easy. Something is either difficult or easy. If you think something is in between difficult and easy then say so. I was frightened that the finals might be difficult this year, however to my surprise, they were not. In this case the writer does not *precisely* quantify the difficulty of his final exams, however, we can infer that the difficulty level falls somewhere between easy-peasy and devilishly-difficult -- WITHOUT resorting to a language perversion! Listen, you try to make an argument that pretty somehow quantifies the difficulty of an easy task. Okay, if pretty is a quantifier, then what EXACTLY is it's quantity, exactly? You see, you've gained nothing by using pretty. All you have done is to inject clumsiness. I've heard of captains tripping and falling into lifeboats, but this is ridiculous! In all seriousness, the idea that very and somewhat are somehow better in this context than pretty just because pretty has another meaning in other contexts is flatly ridiculous. The editors at dictionary.com disagree with you too: Usage Note The qualifying adverb pretty, meaning “fairly or moderately” has been in general use since the late 16th century. Although most common in informal speech and writing, it is far from restricted to them, and often is less stilted than alternatives such as relatively, moderately, and quite. So you have no capacity to reason on your own without outside influence? I feel horrible for you. All of the classical philosophers would have gulped poison like some college student at an all night kegger if they knew the shameful outcome of our wasted centuries of evolution. Not that dictionary.com is the final authority on the English language, but I'll but a lot more stock in what they say than in a [...]. Of course. Because as we all know, dictionary.com has the worlds best philosophers, linguist, sociologist, and PR departments (apparently). Let's see what intelligent words we can find here... doohickey a name for something one doesn't know the name of, 1914, Amer.Eng., arbitrary formation. thing·a·ma·jig a gadget or other thing for which the speaker does not know or has forgotten the name. Wow, this dictionary has high standards. i stand humbled! -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, Jan 25, 2012 at 12:16 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: In particular i find the extension notation syntax to be woefully inadequate. You should be able to infer the action of the extension syntax intuitively, simply from looking at its signature. This is nice in theory. I see no reason to believe this is possible, or that your syntax is closer to this ideal than the existing syntax. Perhaps you should perform some experiments to prove intuitiveness? Science is more convincing than insults. Also, the ! in negative assertions doesn't stand for not equal -- matches aren't equality. It stands for not. It's the = that's a misnomer. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Wed, Jan 25, 2012 at 3:23 PM, Rick Johnson rantingrickjohn...@gmail.comwrote: On Jan 25, 3:45 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 1:14 PM, Rick Johnson In all seriousness, the idea that very and somewhat are somehow better in this context than pretty just because pretty has another meaning in other contexts is flatly ridiculous. The editors at dictionary.com disagree with you too: Usage Note The qualifying adverb pretty, meaning “fairly or moderately” has been in general use since the late 16th century. Although most common in informal speech and writing, it is far from restricted to them, and often is less stilted than alternatives such as relatively, moderately, and quite. So you have no capacity to reason on your own without outside influence? I feel horrible for you. All of the classical philosophers would have gulped poison like some college student at an all night kegger if they knew the shameful outcome of our wasted centuries of evolution. Not that dictionary.com is the final authority on the English language, but I'll but a lot more stock in what they say than in a [...]. Of course. Because as we all know, dictionary.com has the worlds best philosophers, linguist, sociologist, and PR departments (apparently). Let's see what intelligent words we can find here... doohickey a name for something one doesn't know the name of, 1914, Amer.Eng., arbitrary formation. thing·a·ma·jig a gadget or other thing for which the speaker does not know or has forgotten the name. Would you prefer the Oxford or Merriam-Webster dictionaries. They are a bit more established than dictionary.com in terms of standardizing the languages. Definition 4 of the Merriam-Webster dictionary for pretty as an adjective says: moderately large *:* considerablehttp://www.merriam-webster.com/dictionary/considerable a very *pretty* profitcost a *pretty* penny See: http://www.merriam-webster.com/dictionary/pretty The only definition for pretty as an adjective in the Oxford dictionary says: *[*as submodifier] *informal* to a moderately high degree; fairly: he looked pretty fit for his age See: http://oxforddictionaries.com/definition/pretty?q=pretty As such, I would say using pretty as an adjective for fairly, considerably, or other, as in the sentence That was pretty easy. is well established and accepted English. So far there have been three dictionary entries saying it is valid English, including one of the most widely accepted. - Wow, this dictionary has high standards. i stand humbled! -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, Jan 25, 2012 at 2:19 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: I disagree here. Whist some people may be die-hard fans of the un-intuitive perl regex syntax, i believe many, if not exponentially MORE people would like to have a better alternative. Do i want to remove the current well established re module? No. But i would like to create a new regex module that is more pythonic. A regex module that we can be proud of. And just maybe, a regex module that sets the bar for all other regular expressions. Compact regex notations are inherently unpythonic. While your reimplementation may be more intuitive to you, I don't think that it's more pythonic at all. Window dressing is important Ian, if not, then shop owners would not continue to show displays in their shop windows. What does window dressing do exactly? It attracts the masses, and without the masses all merchants will eventually go out of buisness. Note: my argument HAS NOTHING to do with the number of folks programming python (or any language). The argument is focused on module sustainability in a community. Modules that are morbidly DIFFICULT to learn do not last. Well, FWIW, I think that the current re module was easier for me to learn than your version would have been, mainly because the re module matches the syntax that I was already familiar with well before I started using Python. If you think you can do better, though, I encourage you to actually write your regex module and put it up on PyPI. I know about PyParsing but i believe we have room for PyParsing and a more Pythonic take on Perl style regular expressions. I don't see why we could not keep all three. Let the people decide what is best for them. PyParsing produces recursive descent parsers. It's an alternative to regular expressions for a different class of parsing problems, not a replacement, and so it's not particularly germane to this discussion. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Jan 25, 5:28 pm, Devin Jeanpierre jeanpierr...@gmail.com wrote: Perhaps you should perform some experiments to prove intuitiveness [of your syntax]? I've posted my thoughts and my initial syntax. You (and everyone else) are free to critic or offer suggestions of your own. Listen, none of these issues that plague Python are going to be resolved until people around here set aside the grudges and haughty arrogance. We need to get to work. But step one is NOT writing code. Step one is to gather the community into lively discussion on these crucial topics. And the folks who really want to get involved are not going to speak up unless the rhetoric is toned down a bit. Science is more convincing than insults. I can assure you my intentions are not to insult. My blanket observations is that the current Python re syntax is not intuitive enough for Python, and that we can make it better. -- http://mail.python.org/mailman/listinfo/python-list
Re: Find the mime type of a file.
On Jan 25, 5:04 pm, Olive di...@bigfoot.com wrote: I want to have a list of all the images in a directory. To do so I want to have a function that find the mime type of a file. I have found mimetypes.guess_type but it only works by examining the extension. In GNU/Linux the file utility do much better by actually looking at the file. Is there an equivalent function in python (as a last resort I can always use the external file utility). Olive You could also try using PIL.(I hardly use it, but...) from PIL import Image for fname in [some list of filenames here]: img = Image.open(fname) print img.format Might be more expensive than the file utility, but that's up to you to determine (open might be lazy, or it might load it - there is a separate load function though, so who knows). hth, Jon. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Jan 25, 5:36 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 2:19 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: I disagree here. Whist some people may be die-hard fans of the un-intuitive perl regex syntax, i believe many, if not exponentially MORE people would like to have a better alternative. Do i want to remove the current well established re module? No. But i would like to create a new regex module that is more pythonic. A regex module that we can be proud of. And just maybe, a regex module that sets the bar for all other regular expressions. Compact regex notations are inherently unpythonic. While your reimplementation may be more intuitive to you, I don't think that it's more pythonic at all. Regexps will never be truly Pythonic. By their very nature they must be implicit, complicated, most times nested and dense, not as readable as we'd like, special cases everywhere, not very practical, hard(sic) to explain, and just plain cryptic. They violate almost every aspect of the zen. The point is NOT to make regexes Pythonic, the point is to make them as Pythonic as we can and not a bit more. I discussed this very topic earlier, did you miss my speech? I though it was quite elegant... Rick Johnsons stump speech 2.0: The greatest aspect of regexes is their compactness, and not only should we keep them compact, we should celebrate their compactness. It is in that respect that regexes will always be cryptic to the neophyte, however, we must NEVER allow regexes to be a scourge on the initiated, no. We must balance the compact and the intuitive natures of regexes until we reach a natural harmony. But most importantly, we must understand that these aspects of regexes are NOT mutually exclusive -- for it is our understanding that is flawed. *applause* I know about PyParsing but i believe we have room for PyParsing and a more Pythonic take on Perl style regular expressions. I don't see why we could not keep all three. Let the people decide what is best for them. PyParsing produces recursive descent parsers. It's an alternative to regular expressions for a different class of parsing problems, not a replacement, and so it's not particularly germane to this discussion. It is germane in the fact that i believe PyParsing, re, and my new regex module can co-exist in harmony. -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Wed, Jan 25, 2012 at 4:23 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: Only to you. In my world, the pleasurable aspects of a tangible object can have no effect on my opinion of the difficulty of a task. Then your world is not the real world, that being the one that is actually described by every dictionary that I've checked. Pretty easy is generally understood to be not quite as easy as just easy. So why not say slightly easy? Slightly can inject quantity into another word, whereas pretty cannot. Pretty has no quantity Just as pretty can mean pleasing, slight can mean delicate. So I seriously do not understand why you object to one as a qualifier and not the other, when both are frequently used as such. simply use any number of legal QUANTIFIERS. I think XYZ is VERY easy or I think XYZ is SOMEWHAT easy or I think XYZ is difficult. Now, don't be ridiculous. Obviously, the One True Meaning of very is precise or particular, as in That is the very thing I was looking for. You don't need to quantify easy. Something is either difficult or easy. If you think something is in between difficult and easy then say so. I was frightened that the finals might be difficult this year, however to my surprise, they were not. In this case the writer does not *precisely* quantify the difficulty of his final exams, however, we can infer that the difficulty level falls somewhere between easy-peasy and devilishly-difficult -- WITHOUT resorting to a language perversion! That is not what I infer from that sentence. I take from it that the writer expected the finals to be difficult, and they turned out to be the opposite (i.e. easy). If you thought that that sentence clearly implied that the finals were between easy and difficult, then your writing skills stink. Listen, you try to make an argument that pretty somehow quantifies the difficulty of an easy task. Okay, if pretty is a quantifier, then what EXACTLY is it's quantity, exactly? You see, you've gained nothing by using pretty. It is a qualifier, not a quantifier, just like very and somewhat, which you have previously advocated. Tell me, if something is very easy, EXACTLY how easy is it? Or do you gain nothing by using those words either? So you have no capacity to reason on your own without outside influence? I feel horrible for you. All of the classical philosophers would have gulped poison like some college student at an all night kegger if they knew the shameful outcome of our wasted centuries of evolution. No, actually what I have demonstrated by going to a dictionary is the capacity to cite external evidence that bolsters my conclusions, rather than simply insisting that everything I say is obviously true. Are you able to do that as well? Or are you so egotistical that you believe you don't need to? Not that dictionary.com is the final authority on the English language, but I'll but a lot more stock in what they say than in a [...]. Of course. Because as we all know, dictionary.com has the worlds best philosophers, linguist, sociologist, and PR departments (apparently). I said Not that dictionary.com is the final authority on the English language, and you interpret my statement to mean dictionary.com has the worlds best philosophers, linguist, sociologist, and PR departments? As long as we're on the topic of dictionaries, I suggest you look up straw man, because that is what your argument amounts to here. And let me tell you, the world's best philosophers would all agree that it's fallacious. Let's see what intelligent words we can find here... doohickey a name for something one doesn't know the name of, 1914, Amer.Eng., arbitrary formation. thing·a·ma·jig a gadget or other thing for which the speaker does not know or has forgotten the name. Wow, this dictionary has high standards. i stand humbled! Are you seriously arguing that an English dictionary should be discredited because it includes English words (even if they are informal)? Not only is that an ad hominem (against a dictionary, no less!), but it is also positively the most moronic thing I have heard today. -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
I just came home. It is 01h19 AM here in Algiers (Algeria, North Africa.. Not New Orleans) and I find this funny thread. Thank you, by the way. I started communicating in English about two years ago, mostly on human sciences topics and was forced to articulate ideas and concepts in this language. I speak several other languages and dialects (French, Kabyle, Arabic and Algiers dialect which can't be understood by other people.. Although I understand no problem Syrian, Lebanese, Egyptian and other dialects. Something about Algerian dialects that gets people confused) Anyway, I've learned mostly by emulating others, remembering idioms and expressions of everyday life. That and watching many movies (in English instead of French), and switching my technical documentation to English. I have been raised reading Antoine de Saint Exupéry, Alexandre Dumas, Honoré de Balzac, Jules Verne, Jean Racine, Molière and many other great writers. I am sincerely sorry if my English offends some purists, but I am making efforts to write correctly, and making mistakes to learn. To learn this and many other things... Things like Python. Which is why I am on this list in the first place. Brilliant list, by the way. Gentlemen, I wish you a good night. -- ~Jugurtha Hadjar, -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Wed, 25 Jan 2012 15:38:12 -0800 Chris Kaynor ckay...@zindagigames.com wrote: [...] Would you prefer the Oxford or Merriam-Webster dictionaries. They are a bit more established than dictionary.com in terms of standardizing the languages. Definition 4 of the Merriam-Webster dictionary for pretty as an adjective says: moderately large *:* considerablehttp://www.merriam-webster.com/dictionary/considerable a very *pretty* profitcost a *pretty* penny See: http://www.merriam-webster.com/dictionary/pretty The only definition for pretty as an adjective in the Oxford dictionary says: *[*as submodifier] *informal* to a moderately high degree; fairly: he looked pretty fit for his age See: http://oxforddictionaries.com/definition/pretty?q=pretty As such, I would say using pretty as an adjective for fairly, considerably, or other, as in the sentence That was pretty easy. is well established and accepted English. So far there have been three dictionary entries saying it is valid English, including one of the most widely accepted. No doubt His Rantingness has already widened the scope of his spampaign to include the world's lexicographers and the billion or so English speakers they represent, with the aim of liberating them all from their sad misapprehensions about what constitutes valid colloquial English, and by example, their burdensome preoccupations with spelling and punctuation, and their crippling fear of malapropisms and homonyms. John -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Wed, 25 Jan 2012 12:14:43 -0800, Rick Johnson wrote: PS: Just like i suspected; not one single use of pretty was wielded to describe the pleasurable attributes of a person, place, or thing. Mind boggling! Have you even bothered to look up pretty in the dictionary? Dictionary.com has this usage note: The qualifying adverb pretty, meaning fairly or moderately has been in general use since the late 16th century. Although most common in informal speech and writing, it is far from restricted to them, and often is less stilted than alternatives such as relatively, moderately, and quite. so your complaints are about 400 years late. Perhaps you don't know as much about the English language as you think. The Oxford Dictionary lists the first definition of pretty as Orig. cunning, crafty. Later (of a person) clever, skillful; (of a thing) cleverly made or done, ingenious, artful. and states that it is derived from Old English praettig, capricious, overbearing. Other meanings include: excellent or admirable in appearance brave, gallant, warlike (this one is chiefly Scots) Of a person, esp. a woman or child: attractive and pleasing in appearance; beautiful in a delicate, dainty or diminutive way without stateliness Of a quantity or amount: considerable, great To a considerable extent, considerably; fairly, moderately, tolerably I think it is absolutely wonderful that the English language has evolved in such a way that pretty means both warlike and dainty :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On 1/25/12 12:14 , Rick Johnson wrote: You don't even need pretty to get your point across. If that's your argument, then we can drop the verb to be, most articles, most verb conjugations, and nearly all adjectives and adverbs. For that matter, the vast majority of posts here can be dropped as they don't convey any new factual knowledge at all. Terseness isn't the only goal of language. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Jan 25, 6:20 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 4:23 PM, Rick Johnson I was frightened that the finals might be difficult this year, however to my surprise, they were not. In this case the writer does not *precisely* quantify the difficulty of his final exams, however, we can infer that the difficulty level falls somewhere between easy-peasy and devilishly-difficult -- WITHOUT resorting to a language perversion! That is not what I infer from that sentence. I take from it that the writer expected the finals to be difficult, and they turned out to be the opposite (i.e. easy). If you thought that that sentence clearly implied that the finals were between easy and difficult, then your writing skills stink. My writing skills are not in question here, however your reading and comprehension skills should be. How could you possibly know for sure, beyond any reasonable doubt, that the writer was suggesting the final exam was easy? In fact, the writer never even mentioned the word easy at all! The writer only stated that the test was NOT *difficult*. How does not difficult extrapolate to easy. The only fact you can be sure of is that the difficulty of the exam is somewhere in range between easy-peasy and devilishly-difficult. You seem to see the world in only black and white now, whereas earlier you could see all sorts of gray shades in the supposed quantity of pretty. Listen, you try to make an argument that pretty somehow quantifies the difficulty of an easy task. Okay, if pretty is a quantifier, then what EXACTLY is it's quantity, exactly? You see, you've gained nothing by using pretty. It is a qualifier, not a quantifier, Oh i see, NOW it's a qualifier! So what is easy qualified for? 1. A zero interest loan? 2. A sweepstakes? or maybe you meant qualified as 1. a traffic cop? 2. a clumsy ship captain? or maybe you meant has authority to qualify, clown: In the name of the people and things of Hell, I dub thee... Spawn, general of Hell's armies. Arise, Your Crispness! Arise, Duke of Deep-Fried! Sultan of Sizzling! Emir of Ooey-Gooey! *[Thought Exercise]* Take a word like applause. Let's say we want to quantify the level of applause to some variable degree of precision. We could say: roaring applause, even though the base definition of roaring is a sound an animal creates. You see roaring can make the transformation whilst pretty cannot. Why? Because the base definition of roaring refers to magnitude of sound. In that sense, an applause can roar. But the applause can never be pretty loud because pretty is 1) not a quantifier 2) cannot make the transformation to quantify sound. Pretty is not a quantifier, it's an observation, or an opinion if you like. just like very and somewhat, which you have previously advocated. Tell me, if something is very easy, EXACTLY how easy is it? Or do you gain nothing by using those words either? So you have no capacity to reason on your own without outside influence? I feel horrible for you. All of the classical philosophers would have gulped poison like some college student at an all night kegger if they knew the shameful outcome of our wasted centuries of evolution. No, actually what I have demonstrated by going to a dictionary is the capacity to cite external evidence that bolsters my conclusions, rather than simply insisting that everything I say is obviously true. Are you able to do that as well? Or are you so egotistical that you believe you don't need to? Obviously i have (like many before me) stood on the shoulders of giants to reach the cookie jar of knowledge. I make no allusions otherwise. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, 25 Jan 2012 09:16:01 -0800, Rick Johnson wrote: In particular i find the extension notation syntax to be woefully inadequate. You should be able to infer the action of the extension syntax intuitively, simply from looking at its signature. I find myself continually needing to consult the docs because of the lacking or misleading style of the current syntax. Consider: The only intuitive interface is the nipple. Everything else is learned. Nevertheless, there are legitimate problems with Python's regex syntax. It is based on Perl's syntax, and even Larry Wall agrees that it has some serious problems. Read Apocalypse 5: Wall gives a fantastic explanation of what's wrong with current regex syntax (without such trivial platitudes as it is not intuitive, as if we can all agree on what it intuitive), why it has become that way, and what Perl 6 will do about it. http://www.perl.com/pub/2002/06/04/apo5.html Regexes are essentially a programming language. They may or may not be Turing complete, depending on the implementation (true regexes are not, but Perl regexes are more powerful than true regexes), but they are still a programming language. And users want regexes to be concise, otherwise they would ask for richer string search methods and avoid regexes altogether. The problem is that conciseness and readability are usually (but not always) in opposition. So regexes will never be as readable as Python code, because the requirements of regexes -- that they be short, concise, and usually written as one-liners (or at least one-liners must be possible) -- do not meet Python standards of readability. How can they? Regexes are shorthand. If you want longhand, write your search in straight Python. PS: In my eyes, Python 3000 is already a dinosaur. We look forward to seeing your re-write. I'm sure all right-thinking programmers will flock to your Python fork as soon as you start writing it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, 25 Jan 2012 16:14:09 -0800, Rick Johnson wrote: It is germane in the fact that i believe PyParsing, re, and my new regex module can co-exist in harmony. You don't have a new regex module. When you have written it, then you will have a new regex module. Until then, you're all talk. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Wed, Jan 25, 2012 at 6:00 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: On Jan 25, 6:20 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 4:23 PM, Rick Johnson I was frightened that the finals might be difficult this year, however to my surprise, they were not. In this case the writer does not *precisely* quantify the difficulty of his final exams, however, we can infer that the difficulty level falls somewhere between easy-peasy and devilishly-difficult -- WITHOUT resorting to a language perversion! That is not what I infer from that sentence. I take from it that the writer expected the finals to be difficult, and they turned out to be the opposite (i.e. easy). If you thought that that sentence clearly implied that the finals were between easy and difficult, then your writing skills stink. My writing skills are not in question here, however your reading and comprehension skills should be. How could you possibly know for sure, beyond any reasonable doubt, that the writer was suggesting the final exam was easy? In fact, the writer never even mentioned the word easy at all! The writer only stated that the test was NOT *difficult*. How does not difficult extrapolate to easy. That may be the literal meaning, but English composition does not always follow the rules of predicate logic. To me, the emphatic use of to my surprise in the construction I expected X, but to my surprise I found it was not implies not merely the literal not X but actually the opposite of X; and the opposite of difficult is easy. Feel free to call my reading comprehension skills into question all you like, but remember that it is the writer, not the reader, who chooses the words he uses to convey his ideas, and so it is a poor writer indeed who blames his audience for a failure to communicate. Listen, you try to make an argument that pretty somehow quantifies the difficulty of an easy task. Okay, if pretty is a quantifier, then what EXACTLY is it's quantity, exactly? You see, you've gained nothing by using pretty. It is a qualifier, not a quantifier, Oh i see, NOW it's a qualifier! I don't recall ever saying otherwise. So what is easy qualified for? 1. A zero interest loan? 2. A sweepstakes? or maybe you meant qualified as 1. a traffic cop? 2. a clumsy ship captain? or maybe you meant has authority to qualify, Or more likely I meant: 2. Grammar . b. an adverb that modifies adjectives or other adverbs and typically expresses degree or intensity, as very, somewhat, or quite. (dictionary.com) But I think that you knew that and are being deliberately obtuse as a means of evasion. *[Thought Exercise]* Take a word like applause. Let's say we want to quantify the level of applause to some variable degree of precision. We could say: roaring applause, even though the base definition of roaring is a sound an animal creates. You see roaring can make the transformation whilst pretty cannot. Why? Because the base definition of roaring refers to magnitude of sound. In that sense, an applause can roar. But the applause can never be pretty loud because pretty is 1) not a quantifier 2) cannot make the transformation to quantify sound. Pretty is not a quantifier, it's an observation, or an opinion if you like. I will agree that roaring applause, while a bit cliche, is more expressive than pretty loud applause. That does not invalidate pretty loud applause as a meaningful phrase, any more than it invalidates very loud applause or slightly loud applause. I'm not interested in continuing a pointless back-and-forth over whether pretty is a real adverb, though, so I'll leave it at that. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On 01/25/2012 06:54 PM, Steven D'Aprano wrote: The only intuitive interface is the nipple. Everything else is learned. I think young mothers would even disagree with that. It's learned just like everything else in life. Albeit very rapidly. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, Jan 25, 2012 at 7:14 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: It is germane in the fact that i believe PyParsing, re, and my new regex module can co-exist in harmony. If all you're going to change is the parser, maybe it'd be easier to get things to coexist if parsers were pluggable in the re module. It's more generally useful, too. Would let re gain a PyParsing/SNOBOL like expression syntax, for example. Or a regular grammar syntax. Neat for experimentation. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Jan 25, 6:28 pm, Jugurtha Hadjar jugurtha.had...@gmail.com wrote: I am sincerely sorry if my English offends some purists, but I am making efforts to write correctly, and making mistakes to learn. To learn this and many other things... Hello Jugurtha, You English does not offend me. i want you to realize that i am not directing my complaints towards anyone who speaks English as a second language. The many problems with the English language are manifesting themselves internally. We are drilling holes in the bottom our own wooden ships and then becoming confused when they fill with water. The lemmings are full speed towards the precipice. Given your rich knowledge of so many languages, I would very much like you to weigh in on the superfluous usage of words like pretty, the bogus transformations of contextual meaning, and the other perversions you have burdened you whist learning this language. -- http://mail.python.org/mailman/listinfo/python-list
import fails in non-interactive interpreter
I've been banging my head against this for the past hour, and I'm hoping someone here can set me straight. I have a virtualenv setup for a Pyramid app and I'm having trouble importing the paste.deploy module in a standalone, non-Pyramid script within the virtualenv. For testing purposes I have a one line test.py file: from paste.deploy import appconfig python test.py ImportError: No module named paste.deploy but, using the same same python, I'm able to import the module from the interactive interpreter. The PATH and PYTHONPATH environment variables are identical in both contexts. Under what situations would a module be available to through the interactive interpreter but not the non-interactive? I greatly appreciate any thoughts, Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Jan 25, 8:02 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 6:00 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: On Jan 25, 6:20 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 25, 2012 at 4:23 PM, Rick Johnson My writing skills are not in question here, however your reading and comprehension skills should be. How could you possibly know for sure, beyond any reasonable doubt, that the writer was suggesting the final exam was easy? In fact, the writer never even mentioned the word easy at all! The writer only stated that the test was NOT *difficult*. How does not difficult extrapolate to easy. That may be the literal meaning, but English composition does not always follow the rules of predicate logic. To me, the emphatic use of to my surprise in the construction I expected X, but to my surprise I found it was not implies not merely the literal not X but actually the opposite of X; and the opposite of difficult is easy. I am not arguing that the exam was not easy, maybe it was easy, i dunno? But from the lack of detail given, we can never be absolutely sure. The possible subjective range of difficulty lies somewhere between easy and anything up to, BUT NOT INCLUDING, difficult. In that sense the exam could have been easy, slightly easy, moderately easy, or slightly difficult. Difficulty and difficult are not interchangeable. Anyway, the point is we can never be sure of the precision in this case, and using pretty offers the same level of ambiguity as not using a quantifier -- even though pretty IS NOT a quantifier :-). That is the connection i wanted you to understand. *[Thought Exercise]* Take a word like applause. Let's say we want to quantify the level of applause to some variable degree of precision. We could say: roaring applause, even though the base definition of roaring is a sound an animal creates. You see roaring can make the transformation whilst pretty cannot. Why? Because the base definition of roaring refers to magnitude of sound. In that sense, an applause can roar. But the applause can never be pretty loud because pretty is 1) not a quantifier 2) cannot make the transformation to quantify sound. Pretty is not a quantifier, it's an observation, or an opinion if you like. I will agree that roaring applause, while a bit cliche, is more expressive than pretty loud applause. The phrase is not just more expressive, roaring IS a legit quantifier, with the power to inject magnitude and make the transformation all WITHOUT perverting its base definition. That does not invalidate pretty loud applause as a meaningful phrase, any more than it invalidates very loud applause or slightly loud applause. I'm not interested in continuing a pointless back-and-forth over whether pretty is a real adverb, though, so I'll leave it at that. I believe we'll just have to agree to disagree on the issue of pretty. However, let's take a step back and view this issue from a global perspective. Ask yourself: Q: Am i choosing my words carefully, or just blindly imitating others to the detriment of my own thought patterns? -- http://mail.python.org/mailman/listinfo/python-list
Re: import fails in non-interactive interpreter
On Wed, Jan 25, 2012 at 9:25 PM, Brian brian.brine...@gmail.com wrote:
Under what situations would a module be available to through the
interactive interpreter but not the non-interactive?
I don't know if it matches your situation, but one such case is this:
The interactive interpreter (and the interpreter with the -c flag) add
the current working directory ('') to the module import search path
(sys.path). Regular python execution does not. So modules in the
current working directory can always be imported from the interactive
interpreter, but not necessarily if you run python on a source file.
-- Devin
--
http://mail.python.org/mailman/listinfo/python-list
Re: Where to put data
On 01/25/2012 03:29 PM, bvdp wrote: Right now my program does a search for modules in all the normal places, which seems to work for windows, mac and linux. Once the modules are found I just insert that location into sys.path[0]. Which permits the modules to reside anywhere on the HDD. However, I have feeling that this isn't quite pythonic Unless you are writing a python library that will be used by others, I don't think that where you put your files has anything to do with being pythonic or not. Just do what works for your OS. On Linux, many packages written in many languages have to deal with the problem of where to put their files. For example, firefox, even when installed as a package on Fedora, puts just about everything in /usr/lib/firefox-#.#, and then symlinks the start binary back into /usr/bin. Other packages, such as Calibre, put things in /usr/lib/calibre (most python modules go here), and some things like extension scripts in /usr/share/calibre. Other packages usr /usr/libexec/packagename/. In the case of both firefox and calibre, if you install from tarball it makes a firefox or calibre folder in a place of your choosing and dumps its stuff inside, sometimes with a mini-unix directory structure (bin, share, lib etc). On Mac of course, you can put everything in your application bundle. That's how most standalone apps written in python work. On Windows you could stick all your python modules in your application's directory in Program Files. -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Thu, Jan 26, 2012 at 2:01 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: I believe we'll just have to agree to disagree on the issue of pretty. However, let's take a step back and view this issue from a global perspective. Ask yourself: Q: Am i choosing my words carefully, or just blindly imitating others to the detriment of my own thought patterns? I'm choosing my words carefully: Rick, you are a troll, and at the moment, you are being eclipsed in intelligence by 8. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Jan 25, 8:24 pm, Devin Jeanpierre jeanpierr...@gmail.com wrote: On Wed, Jan 25, 2012 at 7:14 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: It is germane in the fact that i believe PyParsing, re, and my new regex module can co-exist in harmony. If all you're going to change is the parser, maybe it'd be easier to get things to coexist if parsers were pluggable in the re module. It's more generally useful, too. Would let re gain a PyParsing/SNOBOL like expression syntax, for example. Or a regular grammar syntax. Neat for experimentation. I like your idea. Not sure about feasibility though. Unfortunately the Python module re is under proprietary copyright. Hmm, seems not everything is completely open source in the python world. # This version of the SRE library can be redistributed under CNRI's # Python 1.6 license. For any other use, please contact Secret Labs # AB (i...@pythonware.com). I need to dive into the re base code and see what is possible. My original idea was to just start from scratch, but that may be foolish considering all the scaffolding that will need to be erected. -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Wed, 25 Jan 2012 15:23:10 -0800, Rick Johnson wrote: Let's see what intelligent words we can find here... doohickey a name for something one doesn't know the name of, 1914, Amer.Eng., arbitrary formation. thing·a·ma·jig a gadget or other thing for which the speaker does not know or has forgotten the name. Wow, this dictionary has high standards. i stand humbled! If only you did. You might learn something. Rick, you mock what you do not understand. Shame on you. Doohickey and thing-a-ma-jig (or thingumajig) are metasyntactic variables like foo/bar/baz or spam/ham/eggs. They are real words used by real people, not just in speech but in writing, and it is the job of the dictionary compiler to document actual words used by people, not to make arbitrary rules that some words aren't good enough. Dictionaries should be descriptive, not prescriptive. We do not need or want an Académie Française for English, especially not one that would impoverish the English language and reduce it to a poor shadow of itself by taking away fine distinctions of meaning. Being able to distinguish between widget, gadget, doohickey, thingy, whatsit, wossname, etc. is a feature, not a bug. It is part of the richness of English that we aren't limited to just a single word, thing, to describe multiple things. In a single sentence, we can easily use thing to refer to generic, abstract objects or concepts, and doohickey, whatsit, etc. to refer to *specific*, concrete objects whether or not they have a name. These words are as rich and powerful as older words like organ, part, stuff, bits, all of which have subtle differences of meaning. In the same way that a native English speaker would never make the mistake of using organ to refer to an unnamed mechanical device, so she would never use gadget to refer to an unnamed body part. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Thu, Jan 26, 2012 at 4:14 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: In the same way that a native English speaker would never make the mistake of using organ to refer to an unnamed mechanical device, so she would never use gadget to refer to an unnamed body part. I dunno... every Sunday I press keys on a keyboard at church, and I'm pretty sure that's a mechanical device. Well, electrical and mechanical, but not living. But that's another specific meaning, and it would be equally incorrect to call that a gadget as to call my lung one. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, 25 Jan 2012 15:44:35 -0800, Rick Johnson wrote: I've posted my thoughts and my initial syntax. You (and everyone else) are free to critic or offer suggestions of your own. Listen, none of these issues that plague Python are going to be resolved until people around here set aside the grudges and haughty arrogance. We need to get to work. But step one is NOT writing code. Well, that suits you well then, since you're an expert on not writing code. How is that fork of Python coming along? I really look forward to the day that you make good on your promise to fork the language so all the right- thinking people can follow you to the Promised Land. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
The contents of this thread ostensibly argues about the word 'pretty' Actually it seems to be arguing about the word 'troll' Every other post calls the OP a troll and then outdoes his post in length. This does not match any meaning I can make of trolling. Can someone please explain what 'troll' means? -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On Wed, 25 Jan 2012 13:17:11 -0700, Ian Kelly wrote: 2) Permitting flags in the regular expression allows different combinations of flags to be in effect for different parts of complex regular expressions. You can't do that just by passing in the flags as an argument. I don't believe Python's regex engine supports scoped flags, I think all flags are global to the entire regex. MRAB's regex engine does support scoped flags. http://pypi.python.org/pypi/regex -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PyWart: Python regular expression syntax is not intuitive.
On 1/25/2012 20:24, Devin Jeanpierre wrote: If all you're going to change is the parser, maybe it'd be easier to get things to coexist if parsers were pluggable in the re module. It's more generally useful, too. Would let re gain a PyParsing/SNOBOL like expression syntax, for example. Or a regular grammar syntax. Neat for experimentation. I don't know what would be involved in that, but if it could be made to work, that sounds to me like a remarkably good idea to have come out of this thread. (Now it's time for my own troll: About as good of an idea as no longer calling PCRE-alikes 'regular expressions', because they aren't. Ahhh, got that out of my system. :-)) Evan signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On 26 January 2012 05:25, rusi rustompm...@gmail.com wrote: The contents of this thread ostensibly argues about the word 'pretty' Actually it seems to be arguing about the word 'troll' Every other post calls the OP a troll and then outdoes his post in length. This does not match any meaning I can make of trolling. I'm sorry, how does length relate to how much someone is trolling? Can someone please explain what 'troll' means? Evidently Wikipedia: In Internet slang http://en.wikipedia.org/wiki/Internet_slang, a *troll* is someone who posts inflammatory,[2]http://en.wikipedia.org/wiki/Troll_(Internet)#cite_note-1 extraneous http://en.wiktionary.org/wiki/extraneous#Adjective, or off-topic http://en.wikipedia.org/wiki/Off-topic messages in an online community, such as an online discussion forum, chat room, or blog, with the primary intent of provoking readers into an emotionalhttp://en.wikipedia.org/wiki/Emotion response[3]http://en.wikipedia.org/wiki/Troll_(Internet)#cite_note-PCMAG_def-2 or of otherwise disrupting normal on-topic discussion.[4]http://en.wikipedia.org/wiki/Troll_(Internet)#cite_note-IUKB_def-3 A troll needs an explicit goal of derailing or provoking. This qualifies the OP and, I hope, few of the responses. -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On Wed, Jan 25, 2012 at 10:25 PM, rusi rustompm...@gmail.com wrote: The contents of this thread ostensibly argues about the word 'pretty' Actually it seems to be arguing about the word 'troll' Every other post calls the OP a troll and then outdoes his post in length. I just grepped, and it's hardly every other post. Prior to your own post that word had been used three times in this thread. Thus, by using the word four times in your own message, you have more than doubled the number of times it has been used in this thread. This does not match any meaning I can make of trolling. Can someone please explain what 'troll' means? From Wikipedia: In Internet slang, a troll is someone who posts inflammatory, extraneous, or off-topic messages in an online community, such as an online discussion forum, chat room, or blog, with the primary intent of provoking readers into an emotional response or of otherwise disrupting normal on-topic discussion. If the responses Rick is getting on his off-topic thread are longer than his own posts in it (which I seriously doubt, considering the enormity of his first two posts), that means that he is not just a troll, but a successful troll. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
[issue13858] readline fails on nonblocking, unbuffered io.FileIO objects
Charles-François Natali neolo...@free.fr added the comment: Can this be handled some other way? Yeah, that's an hairy issue. See #13322 for the details. -- nosy: +neologix resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - buffered read() and write() does not raise BlockingIOError ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13858 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13841] multiprocessing should use sys.exit() where possible
Charles-François Natali neolo...@free.fr added the comment: * atexit callbacks are NOT run (although multiprocessing.util._exit_function IS run), It may be a good thing after a fork() (e.g. you don't want to remove the same file twice), but it most definitely looks wrong for a new interpreter process (à la Windows / fork() + exec()). * the main thread does NOT wait for non-daemonic background threads. Same thing here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13322] buffered read() and write() does not raise BlockingIOError
Matt Joiner anacro...@gmail.com added the comment: The patches only fix write? What about read? http://bugs.python.org/issue13858 -- nosy: +anacrolix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13852] Doc fixes with patch
Changes by Boštjan Mejak bostjan.me...@gmail.com: -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9285] Add a profile decorator to profile and cProfile
Changes by Yuval Greenfield ubershme...@gmail.com: -- nosy: +ubershmekel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9285 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()
Nick Coghlan ncogh...@gmail.com added the comment:
David Miller pointed out a shorter spelling:
s.replace('\n', '\n' + (4 * ' '))
Still not particularly obvious to the reader (or writer), though.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13857
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Dave Malcolm dmalc...@redhat.com added the comment: I'm attaching a patch which implements a hybrid approach: hybrid-approach-dmalcolm-2012-01-25-001.patch This is a blend of various approaches from the discussion, taking aspects of both hash randomization *and* collision-counting. It incorporates code from amortized-probe-counting-dmalcolm-2012-01-21-003.patch backport-of-hash-randomization-to-2.7-dmalcolm-2012-01-23-001.patch random-8.patch along with ideas from: http://mail.python.org/pipermail/python-dev/2012-January/115812.html The patch is against the default branch (although my primary goal here is eventual backporting). As per haypo's random-8.patch, a randomization seed is read at startup. By default, the existing hash() values are preserved, and no randomization is performed until a dict comes under attack. This preserves existing behaviors (such as dict ordering) under non-attack conditions. For large dictionaries, it reuses the ma_smalltable area to track the amortized cost of all modifications to this dictionary. When the cost exceeds a set threshold, we convert the dictionary's ma_lookup function from lookdict/lookdict_unicode to a paranoid variant. These variants ignore the hash passed in, and instead uses a new function: PyObject_RandomizedHash(obj) to give a second hash value, which is fixed value for a given object within the process, but not predictable to an attacker for the most high-risk types (PyUnicodeObject and PyBytesObject). This patch is intended as a base for backporting, and takes it as given that we can't expand PyTypeObject or hide something in one of the Py*Methods tables; iirc we've run out of tp_flags in 2.*, hence we're forced to implement PyObject_RandomizedHash via direct ob_type comparison, for the most high-risk types. As noted in http://bugs.python.org/issue13703#msg151870: I would NOT worry about hash repeatability for integers and complex data structures. It is not at the core of the common problem (maybe a couple application specific problems but not a general all python web apps severity problem). Doing it for base byte string and unicode string like objects is sufficient. [We can of course implement hash randomization by default in 3.3, but I care more about getting a fix into the released branches ASAP] Upon transition of a dict to paranoid mode, the hash values become unpredictable to an attacker, and all PyDictEntries are rebuilt based on the new hash values. Handling the awkward case within custom ma_lookup functions allows us to move most of the patch from out of the fast path, and lookdict/lookdict_unicode only need minimal changes (stat gathering for the above cost analysis tracking). Once a dict has transitioned to paranoid mode, it isn't using PyObject_Hash anymore, and thus isn't using cached object values, performing a more expensive calculation, but I believe this calculation is essentially constant-time. This preserves hash() and dict order for the cases where you're not under attack, and gracefully handles the attack without having to raise an exception: it doesn't introduce any new exception types. It preserves ABI, assuming no-one else is reusing ma_smalltable. It is suitable for backporting to 3.2, 2.7, and earlier (I'm investigating fixing this going all the way back to Python 2.2) Under the old implementation, there were 4 types of PyDictObject, given these two booleans: * small vs large i.e ma_table == ma_smalltable vs ma_table != ma_smalltable * all keys are str vs arbitary keys i.e ma_lookdict == lookdict_unicode vs lookdict Under this implementation, this doubles to 8 kinds, adding the boolean: * normal hash vs randomized hash (normal vs paranoid). This is expressed via the ma_lookdict callback, adding two new variants, lookdict_unicode_paranoid and lookdict_paranoid Note that if a paranoid dict goes small again (ma_table == ma_smalltable), it stays paranoid. This is for simplicity: it avoids having to rebuild all of the non-randomized me_hash values again (which could fail). Naturally the patch adds selftests. I had to add some diagnostic methods to support them; dict gains _stats() and _make_paranoid() methods, and sys gains a _getrandomizedhash() method. These could be hidden more thoroughly if need be (see DICT_PROTECTION_TRACKING in dictobject.c). Amongst other things, the selftests measure wallclock time taken for various dict operations (and so might introduce failures on a heavily-loaded machine, I guess). Hopefully this approach is a viable way forward. Caveats and TODO items: TODO: I haven't yet tuned the safety threshold. According to http://bugs.python.org/issue13703#msg151850: slot collisions are much more frequent than hash collisions, which only account for less than 0.01% of all collisions. It also shows that slot collisions in the low 1-10 range are most frequent, with very few instances of a dict lookup reaching 20
