Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wed, 04 Dec 2013 12:35:14 -0800, Piotr Dobrogost wrote: > Right. If there's already a way to have attributes with these > "non-standard" names (which is a good thing) No it is not a good thing. It is a bad thing, and completely an accident of implementation that it works at all. Python does not support names (variable names, method names, attribute names, module names etc.) which are not valid identifiers except by accident. The right way to handle non-identifier names is to use keys in a dictionary, which works for any legal string. As you correctly say in another post: "attribute is quite a different beast then key in a dictionary" attributes are intended to be variables, not arbitrary keys. In some languages, they are even called "instance variables". As they are variables, they should be legal identifiers: spam = 42 # legal identifier name spam\n-ham\n = 42 # illegal identifier name Sticking a dot in front of the name doesn't make it any different. Variables, and attributes, should be legal identifiers. If I remember correctly (and I may not), this issue has been raised with the Python-Dev core developers, including Guido, and their decision was: - allowing non-identifier attribute names is an accident of implementation; - Python implementations are allowed to optimize __dict__ to prohibit non- valid identifiers; - but it's probably not worth doing in CPython. getattr already enforces that the attribute name is a string rather than any arbitrary object. You've also raised the issue of linking attribute names to descriptors. Descriptors is certainly a good reason to use attributes, but it's not a good reason for allowing non-identifier names. Instead of writing: obj.'#$^%\n-\'."' just use a legal identifier name! The above is an extreme example, but the principle applies to less extreme examples. It might be slightly annoying to write obj.foo_bar when you actually want of obj.'foo.bar' or obj.'foo\nbar' or some other variation, but frankly, that's just too bad for you. As far as descriptors go, you can implement descriptor-like functionality by overriding __getitem__. Here's a basic example: class MyDict(dict): def __getitem__(self, key): obj = super(MyDict, self).__getitem__(key) if hasattr(obj, '__get__'): obj = obj.__get__(self) which ought to be close to (but not identical) to the semantics of attribute descriptors. While I can see that there is some benefit to allowing non-identifier attributes, I believe such benefit is very small, and not enough to justify the cost by allowing non-identifier attributes. If I wanted to program in a language where #$^%\n-\'." was a legal name for a variable, I'd program in Forth. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: A cautionary tale
On Wed, 04 Dec 2013 11:16:40 +0200, Frank Millman wrote: [...] > Then I noticed that certain changes were not being written back to the > database. After some investigation, I found the error in a part of my > program that I have not had to look at for ages. When reading data in > from the database, I preserve a copy of the original value. When saving, > I compare that to the current value when deciding which columns need > updating. I do this in the obvious way - > > on reading - > orig_value = value As you know, that is not the obvious way to create a copy. That binds a new name to the same value. To create a copy, you need: orig_value = copy.copy(value) or for lists: orig_value = value[:] I think we've all made the same mistake you have, it's an easy mistake to make, but for an experienced Python code it should also be an easy mistake to identify. Mind you, tracking it down might take a while... > on saving - >if value != orig_value: > this one needs updating > > Have you spotted the deliberate mistake yet? In the case of a JSON list, > orig_value and value point to the same, mutable, list. So when I compare > value with orig_value, they are always the same, whether changes have > been made or not! > > The obvious answer is to store a copy of the list. It was not so obvious > where to make the change, as there were other implications. Eventually I > decided to over-ride the 'getter' for the JSON type, and return > copy(value) instead of value. That way if it is changed and then put > back using the 'setter', the two objects are no longer equal. I have > made that change, done some more testing, and for now it seems ok. I wouldn't do it that way. To my mind, the most obvious way of handling this is to add a "changed" flag to the object, and ensure that any modifications set the flag. Of course, that may end up being more work than the way you've done it, but it will save making potentially many copies of objects which don't need to be copied. > So have the last couple of days been a waste of time? I don't think so. > Is the program a bit cleaner and conceptually sounder? I hope so. > > Why am I telling you all this? No particular reason, just thought some > of you might find it interesting. Thank you for sharing your experiences with us! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: A cautionary tale
"Steven D'Aprano" wrote in message news:[email protected]... > On Wed, 04 Dec 2013 11:16:40 +0200, Frank Millman wrote: > > [...] >> Then I noticed that certain changes were not being written back to the >> database. After some investigation, I found the error in a part of my >> program that I have not had to look at for ages. When reading data in >> from the database, I preserve a copy of the original value. When saving, >> I compare that to the current value when deciding which columns need >> updating. I do this in the obvious way - >> >> on reading - >> orig_value = value > > As you know, that is not the obvious way to create a copy. That binds a > new name to the same value. To create a copy, you need: > > orig_value = copy.copy(value) > > or for lists: > > orig_value = value[:] > True enough, but before I added my new data types, all the types I used were immutable, so I got away with it. [...] > > I wouldn't do it that way. To my mind, the most obvious way of handling > this is to add a "changed" flag to the object, and ensure that any > modifications set the flag. > > Of course, that may end up being more work than the way you've done it, > but it will save making potentially many copies of objects which don't > need to be copied. > > There are two (no, make that three) reasons why I need to preserve the original value - 1. A user can make changes to an object, and then before saving, select 'cancel'. I then restore all values to their originals. 2. I keep an 'audit trail' of changes to data rows, showing before and after values. 3. I use a form of 'optimistic concurrency control' to guard against two users updating the same row at the same time, resulting in one set of changes being overwritten. The classic form adds a 'timestamp' column to the table, which is timestamped on every update. Prior to executing an update, the timestamp is re-read from the database, and if not the same as the original, the update is aborted. My variation is to compare only those columns which have been changed, so I compare the re-read values with the orig_values. The benefit is that an organisation could have one user maintaining, say, credit information, while another may be trying to change the same person's telephone number. With my approach, both will succeed even if executed simultaneously [1]. Frank [1] Not literally simultaneously. All that is required is that one user selects the row, and then before updating it, someone else selects the same row. -- https://mail.python.org/mailman/listinfo/python-list
Packaging a proprietary Python library for multiple OSs
Hi everyone, I am developing a proprietary Python library. The library is currently Windows-only, and I want to also make it available for other platforms (Linux & Mac). I'm writing because I wanted to ask for your expert opinion on how to best do this. The library is currently shipped in the form of a Zip file. This archive contains the compiled Python code for the implementation of my library, plus all dependencies. By placing the Zip file on his PYTHONPATH, the customer can use the library from his Python scripts. Shipping a Zip file with all dependencies included has the following advantages: * No internet access or administrator privileges are required to install the library. * The customer does not have to worry about installing / managing dependencies of my library. It also has the disadvantage that the customer is not (easily) able to use his own versions of my library's dependencies. Even though I am not generating an EXE, I am using py2exe to obtain the distributable Zip file for my library. This "hack" is very convenient, as py2exe allows me to simply say which packages I require and does the work of performing a dependency analysis of the required libraries for me. py2exe automatically generates the Zip file with my (compiled) library code, and all dependencies. Unfortunately, py2exe is only available for Windows. I need to also be able to build it on Linux & Mac, hence change the build process to not use py2exe. My questions are: 1. Is it considered a bad idea in the Python community to ship one large Zip file with all dependencies? From what I have seen, it seems to be an unusual approach, at the least. How do *you* prefer to obtain and install Python libraries? 2. Is it possible to distribute the library in a form that allows for an offline installation without administrator privileges using other tools, such as setuptools? My insight into the state of the art in Python regarding these matters is limited, so I would appreciate advice from someone with more experience in the subject. A hard requirement is that I can only ship binary distributions of my library, as this is a proprietary product. I looked at Distutils and Setuptools, where the recommended approach seems to be to simply ship all sources. Many thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Thursday, December 5, 2013 3:44:50 PM UTC+5:30, Michael Herrmann wrote: > Hi everyone, > > I am developing a proprietary Python library. The library is currently > Windows-only, and I want to also make it available for other platforms (Linux > & Mac). I'm writing because I wanted to ask for your expert opinion on how to > best do this. Wheel is the upcoming standard I think. http://www.python.org/dev/peps/pep-0427/ 1. It would be dishonest to remove the 'upcoming' 2. It would also be dishonest if you thought I know anything about the subject :-) 3. https://groups.google.com/forum/#!forum/python-virtualenv may be a better place to ask -- https://mail.python.org/mailman/listinfo/python-list
Re: Share Code: Laptop Lid State
On Tue, 2013-07-30 at 17:00 +0100, Chris Angelico wrote:
> On Tue, Jul 30, 2013 at 3:06 PM, Devyn Collier Johnson
> wrote:
> > Aloha everyone!
> >I attached a script that I thought I could share with everyone for your
> > help. This Python3 script only works on Unix systems. It prints the current
> > state of the lid. This can be used to make a script that performs some
> > action when the lid is closed or open. The script is licensed under LGPLv3
> > and I will soon upload it to my Launchpad account. Enjoy!
> There's... no Python code in that. Why not simply
> open("/proc/acpi/button/lid/LID/state") and read from it, instead of
> using cat and awk?
The correct way to implement this is to use the power management
services available on the System D-Bus.
Integrating with D-Bus from Python is easy!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Finding keywords
Hi , If you got the solutions please let me know also. I have to implement asap. On Wednesday, 9 March 2011 23:43:26 UTC+5:30, Cross wrote: > On 03/09/2011 01:21 AM, Vlastimil Brom wrote: > > 2011/3/8 Cross: > >> On 03/08/2011 06:09 PM, Heather Brown wrote: > >>> > >>> The keywords are an attribute in a tag called, in the section > >>> called > >>> . Are you having trouble parsing the xhtml to that point? > >>> > >>> Be more specific in your question, and somebody is likely to chime in. > >>> Although > >>> I'm not the one, if it's a question of parsing the xhtml. > >>> > >>> DaveA > >> > >> I know meta tags contain keywords but they are not always reliable. I can > >> parse xhtml to obtain keywords from meta tags; but how do I verify them. To > >> obtain reliable keywords, I have to parse the plain text obtained from the > >> URL. > >> > >> Cross > >> > >> --- news://freenews.netfront.net/ - complaints: [email protected] --- > >> -- > >> http://mail.python.org/mailman/listinfo/python-list > >> > > > > Hi, > > if you need to extract meaningful keywords in terms of data mining > > using natural language processing, it might become quite a complex > > task, depending on the requirements; the NLTK toolkit may help with > > some approaches [ http://www.nltk.org/ ]. > > One possibility would be to filter out more frequent and less > > meaningful words ("stopwords") and extract the more frequent words > > from the reminder., e.g. (with some simplifications/hacks in the > > interactive mode): > > > import re, urllib2, nltk > page_src = > urllib2.urlopen("http://www.python.org/doc/essays/foreword/";).read().decode("utf-8") > page_plain = nltk.clean_html(page_src).lower() > txt_filtered = nltk.Text((word for word in re.findall(r"(?u)\w+", > page_plain) if word not in set(nltk.corpus.stopwords.words("english" > frequency_dist = nltk.FreqDist(txt_filtered) > [(word, freq) for (word, freq) in frequency_dist.items() if freq> 2] > > [(u'python', 39), (u'abc', 11), (u'code', 10), (u'c', 7), > > (u'language', 7), (u'programming', 7), (u'unix', 7), (u'foreword', 5), > > (u'new', 5), (u'would', 5), (u'1st', 4), (u'book', 4), (u'ed', 4), > > (u'features', 4), (u'many', 4), (u'one', 4), (u'programmer', 4), > > (u'time', 4), (u'use', 4), (u'community', 3), (u'documentation', 3), > > (u'early', 3), (u'enough', 3), (u'even', 3), (u'first', 3), (u'help', > > 3), (u'indentation', 3), (u'instance', 3), (u'less', 3), (u'like', 3), > > (u'makes', 3), (u'personal', 3), (u'programmers', 3), (u'readability', > > 3), (u'readable', 3), (u'write', 3)] > > > > > Another possibility would be to extract parts of speech (e.g. nouns, > > adjective, verbs) using e.g. nltk.pos_tag(input_txt) etc.; > > for more convoluted html code e.g. BeautifulSoup might be used and > > there are likely many other options. > > > > hth, > >vbr > I had considered nltk. That is why I said that straightforward frequency > calculation of words would be naive. I have to look into this BeautifulSoup > thing. > > --- news://freenews.netfront.net/ - complaints: [email protected] --- -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
In article <[email protected]>, Michael Herrmann wrote: > 1. Is it considered a bad idea in the Python community to ship one large Zip > file with all dependencies? Yes. > How do *you* prefer to obtain and install Python libraries? "pip install" > 2. Is it possible to distribute the library in a form that allows for an > offline installation without administrator privileges using other tools, > such as setuptools? You can use "pip --find-links" to point pip at a local repository of packages. That solves the offline part. And the "without admin privs" part is solved by setting up a virtualenv. > A hard requirement is that I can only ship binary distributions of my > library, as this is a proprietary product. I looked at Distutils and > Setuptools, where the recommended approach seems to be to simply ship all > sources. Keep in mind that shipping just the pyc files offers very weak protection against people examining your code. Google for "python decompile" and you'll find a number of projects. I'm looking at the docs for uncompyle now, which says: > 'uncompyle' converts Python byte-code back into equivalent Python > source. It accepts byte-code from Python version 2.7 only. > > The generated source is very readable: docstrings, lists, tuples and > hashes get pretty-printed. About the only thing not shipping Python source does is satisfy a check-box requirement that you not ship source. It may make the lawyers and bean-counters happy, but that's about it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Input without line break, is it possible?
On 12/04/2013 09:36 AM, Mark Lawrence wrote: > On 04/12/2013 16:23, Michael Torrie wrote: >> On 12/04/2013 08:38 AM, [email protected] wrote: >>> my question, can i make it in just a single line like, >>> >>> 1 2 3 4 5 6 (and so forth) >>> >>> Can I? >> >> Yes of course. raw_input() is going to give you a string that you can >> then parse any way you want. >> > > That's it lad, you're in detention for one hour. You will write > repeatedly "I should be selling Python 3 instead of Python 2" :) Yup. Though if he is using Python 2, then input() is a real no-no. -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On 12/5/13, 5:14 AM, Michael Herrmann wrote: Even though I am not generating an EXE, I am using py2exe to obtain the distributable Zip file for my library. This "hack" is very convenient, as py2exe allows me to simply say which packages I require and does the work of performing a dependency analysis of the required libraries for me. py2exe automatically generates the Zip file with my (compiled) library code, and all dependencies. If your library and their dependencies are simply .pyc files, then I don't see why a zip collated via py2exe wouldn't work on other platforms. Obviously this point is moot if your library includes true compiled (C-based) extensions. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Dec 5, 2013, at 2:56 AM, rusi wrote: > 3. https://groups.google.com/forum/#!forum/python-virtualenv may be a better > place to ask Am I the only one that sees the irony in this suggestion? Given the long running tirades^H^H^H^H^H^H thread about “Managing Google Groups headaches”? “Pleassse don’t use Google Groupesss. It’sss nasssty. It hurtssess our eyessse with itsss long lineieesss. Unless it ha a ssspecial ned. Then the groupssesss are OK, Ye?" -- https://mail.python.org/mailman/listinfo/python-list
Why Muslims Believe that Islam is the truth ?????????????
Why Muslims Believe that Islam is the truth
Many Christians & Jews don't know that Muslims believe in their prophets and
holy books. Muslims believe that the Bible and the Torah were changed by people
for their personal benefits. This is why God sent Prophet Muhammad, peace be
upon him, not with a new religion, but to correct the people who had gone
astray, those who were worshipping idols and being misguided by their
forefathers.
Islam is the last message to the world and God wants the miracle of Islam to be
witnessed by the people from Prophet Muhammad's, peace be upon him, time till
the day of Judgment. The miracle is the Qu'ran, Muslims holy book.
Many Christians & Jews don't know that Muslims believe in their prophets and
holy books. Muslims believe that the Bible and the Torah were changed by people
for their personal benefits. This is why God sent Prophet Muhammad, peace be
upon him, not with a new religion, but to correct the people who had gone
astray, those who were worshipping idols and being misguided by their
forefathers.
Islam is the last message to the world and God wants the miracle of Islam to be
witnessed by the people from Prophet Muhammad's, peace be upon him, time till
the day of Judgment. The miracle is the Qu'ran, Muslims holy book.
Why is the Qur'an a miracle ?
1- The Qu'ran is an untouchable book : After 1400 years, from the begining of
Prophet Muhammad's, peace be upon him, message, the Qu'ran has not changed in
any way, even as a matter of one charachter. Prooving this is very easy, since
you can compare all the versions of the Qu'ran everywhere in the world and you
will find them all the same. God ensured that this book would be saved from any
changes attempted by human beings. God said in the Qur'an : " We have, without
doubt, sent down the Message; and We will assuredly guard it (from corruption)"
2- The Qu'ran contains many scientific facts that have been discovered recently
using computer systems and microscopes. Many scientists have attended
conferences dealing with this subject and have themselves accepted Islam. These
same scientists have said that it is not possible that Muhammad, peace be upon
him, an illiterate man, who lived 1400 years ago, could have discovered such
things on his own. God said in the Qur'an : "Soon will We show them Our Signs
in the (furthest) regions (of the earth), and in their own souls, until it
becomes manifest to them that this is the Truth. Is it not enough that thy Lord
doth witness all things" ( Quran 41:53 )
3- The Qu'ran, which is in Arabic, was revealed to the people of the Arabian
Gulf who invented the Arabic language. Through Muhammad, peace be upon him,
Allah challenged the people who claimed that a human wrote it to emulate such a
book. No one from the time of the Prophet till now could write a book that
contained the many scientific facts, miracles and similar effects on people
that the Qu'ran did and still does today.
4- The Qu'ran had not one Arabic grammar mistake, which was recognized by the
disbelievers at the time of the Prophet, who were the founders of the Arabic
language.
These are a few examples of why Muslims believe in the Qur'an.
Here are some verses from God to Muslims encouraging them to invite the People
of the Book ( Jews and Christians to Islam ):
God said : {Say: "O People of the Book! Why reject ye the Signs of Allah, when
Allah is Himself witness to all ye do?} (Quran 3:98)
God tell Muslims to say : {..'We believe in that which had been revealed to us
and revealed to you, and our God and your God is One, and unto Him we
surrender} (Quran 29:46)
If you have any questions or would like to know more about the Qu'ran and Islam
please contact me at : [email protected] [email protected]
=
http://en.islamway.net/article/8124
thank you
--
https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Thursday, December 5, 2013 11:56:16 AM UTC+1, rusi wrote: > Wheel is the upcoming standard I think. > http://www.python.org/dev/peps/pep-0427/ I hadn't known of Wheel - thanks for pointing it out! -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Thursday, December 5, 2013 3:09:32 PM UTC+1, Roy Smith wrote: > > 1. Is it considered a bad idea in the Python community to ship one large > > Zip file with all dependencies? > Yes. I see. Unfortunately, the library's users may be non-technical and might not even have experience with Python. The easier the installation process, therefore, the better. > > How do *you* prefer to obtain and install Python libraries? > "pip install" Thanks for this input. > > 2. Is it possible to distribute the library in a form that allows for an > > offline installation without administrator privileges using other tools, > > such as setuptools? > > You can use "pip --find-links" to point pip at a local repository of > packages. That solves the offline part. And the "without admin privs" > part is solved by setting up a virtualenv. Both "pip --find-links" and "virtualenv" sound technically feasible but may be too difficult for my users (especially virtualenv). > > A hard requirement is that I can only ship binary distributions of my > > library, as this is a proprietary product. I looked at Distutils and > > Setuptools, where the recommended approach seems to be to simply ship all > > sources. > Keep in mind that shipping just the pyc files offers very weak > protection against people examining your code. Google for "python > decompile" and you'll find a number of projects. I'm looking at the > docs for uncompyle now, which says: > > 'uncompyle' converts Python byte-code back into equivalent Python > > source. It accepts byte-code from Python version 2.7 only. Very interesting point. Thank you very much for pointing out uncompyle. I had always known that it was easy to decompile .pyc files, but hadn't imagined it to be that easy. I just tried uncompyle with some of our proprietary .pyc files. It took 5 minutes to set up and the results are near-perfect. Scary... :-S We might have to look into tools such as http://www.bitboost.com/#Python_obfuscator to obfuscate our code. Thanks for the valuable insights! Michael -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Thu, Dec 5, 2013, at 10:49, Michael Herrmann wrote: > Very interesting point. Thank you very much for pointing out uncompyle. I > had always known that it was easy to decompile .pyc files, but hadn't > imagined it to be that easy. I just tried uncompyle with some of our > proprietary .pyc files. It took 5 minutes to set up and the results are > near-perfect. Scary... :-S We might have to look into tools such as > http://www.bitboost.com/#Python_obfuscator to obfuscate our code. Or you could just sue anyone who steals your code. -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Thursday, December 5, 2013 4:26:40 PM UTC+1, Kevin Walzer wrote: > On 12/5/13, 5:14 AM, Michael Herrmann wrote: > If your library and their dependencies are simply .pyc files, then I > don't see why a zip collated via py2exe wouldn't work on other > platforms. Obviously this point is moot if your library includes true > compiled (C-based) extensions. As I said, I need to make my *build* platform-independent. Thanks, Michael -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On 12/5/13, 10:50 AM, Michael Herrmann wrote: As I said, I need to make my *build* platform-independent. cx_Freeze is platform independent, but I'm not sure if it generates libraries or simply executables. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Fri, Dec 6, 2013 at 2:32 AM, Travis Griggs wrote: > > On Dec 5, 2013, at 2:56 AM, rusi wrote: > >> 3. https://groups.google.com/forum/#!forum/python-virtualenv may be a better >> place to ask > > Am I the only one that sees the irony in this suggestion? Given the long > running tirades^H^H^H^H^H^H thread about “Managing Google Groups headaches”? > > “Pleassse don’t use Google Groupesss. It’sss nasssty. It hurtssess our > eyessse with itsss long lineieesss. Unless it ha a ssspecial > ned. Then the groupssesss are OK, Ye?" No, it's not like that. It's that there are some people who, despite truckloads of evidence to the contrary, still think that Google Groups is worth using. Rusi is one of them. Fortunately, he has defended his position by making his posts not look like the ridiculous junk that GG creates by default, but that doesn't make GG a good product. It's like an argument my boss and I had: I said that PHP is a bad language, and he said that it can't possibly be a bad language because he's able to write good code in it. I don't know what mailing list there is for virtualenv as I don't use it, but there's likely to be an alternative source of knowledge on it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Thursday, 5 December 2013 16:52:45 UTC+1, [email protected] wrote: > Or you could just sue anyone who steals your code. I see your point but I don't think it's very practical. If the person who stole the code sits in some remote country with a completely different legal system, I think I'll have a hard time getting at this person. If I even manage to find out where the person is at all. -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Thursday, December 5, 2013 11:20:41 AM UTC-5, Chris Angelico wrote: > No, it's not like that. It's that there are some people who, despite > truckloads of evidence to the contrary, still think that Google Groups > > is worth using. Rusi is one of them. Fortunately, he has defended his > > position by making his posts not look like the ridiculous junk that GG > > creates by default, but that doesn't make GG a good product. I use GG on occasion (I'm using it now), when I don't have access to a better newsreader. Like Rusi, I take the effort to clean up the double-space mess GG produces by default. That doesn't mean GG isn't a piece of crap; it is. That fact that I, and Rusi, know enough, and take the effort, to overcome its shortcomings doesn't change that. I put GG it in the category of "attractive nuisance". It's like leaving cans of spray paint laying around school playgrounds and then being surprised when the kids pick them up and use them to paint graffiti. It certainly violates Google's "do no harm" motto when it interacts with usenet groups. I keep hearing that I should use gmane as a superior interface. Well, I tried that. I went to http://dir.gmane.org/search.php, where it asks me to search for a newsgroup. I type in "comp.lang.python", and it tells me, "No matching groups". So, that seems pretty broken to me. > It's like an argument my boss and I had: I said that PHP is a bad language, > and > he said that it can't possibly be a bad language because he's able to > write good code in it. PHP is a disaster of a language. But, like any bad tool, a good craftsman can produce a quality product with it. Wikipedia is written in PHP. So, apparently, is gmane :-) As much as I loathe working with PHP, I have to admit that if you can build a product like Wikipedia on it, it must have some redeeming qualities. -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On 05/12/2013 16:20, Chris Angelico wrote: On Fri, Dec 6, 2013 at 2:32 AM, Travis Griggs wrote: On Dec 5, 2013, at 2:56 AM, rusi wrote: 3. https://groups.google.com/forum/#!forum/python-virtualenv may be a better place to ask Am I the only one that sees the irony in this suggestion? Given the long running tirades^H^H^H^H^H^H thread about “Managing Google Groups headaches”? “Pleassse don’t use Google Groupesss. It’sss nasssty. It hurtssess our eyessse with itsss long lineieesss. Unless it ha a ssspecial ned. Then the groupssesss are OK, Ye?" No, it's not like that. It's that there are some people who, despite truckloads of evidence to the contrary, still think that Google Groups is worth using. Rusi is one of them. Fortunately, he has defended his position by making his posts not look like the ridiculous junk that GG creates by default, but that doesn't make GG a good product. It's like an argument my boss and I had: I said that PHP is a bad language, and he said that it can't possibly be a bad language because he's able to write good code in it. I don't know what mailing list there is for virtualenv as I don't use it, but there's likely to be an alternative source of knowledge on it. ChrisA gmane.comp.python.virtualenv -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Fri, Dec 6, 2013 at 4:12 AM, Roy Smith wrote: >> It's like an argument my boss and I had: I said that PHP is a bad language, >> and >> he said that it can't possibly be a bad language because he's able to >> write good code in it. > > PHP is a disaster of a language. But, like any bad tool, a good craftsman > can produce a quality product with it. Wikipedia is written in PHP. So, > apparently, is gmane :-) As much as I loathe working with PHP, I have to > admit that if you can build a product like Wikipedia on it, it must have some > redeeming qualities. Right. And the fact that Wikipedia can be written in PHP is not itself proof that it's a good language. You and Rusi are fighting against GG's faults and not entirely succeeding, as your paragraphs come out unwrapped; that's possibly the least of the GG woes, but it's one of the first clues that someone's replies are likely to be double-spaced. A good tool does most of your work for you. A bad tool has to be fought every inch of the way. Sometimes a tool is good but wrongly chosen (don't use DeScribe Macro Language for writing a GUI - drop to REXX for that!), but some tools have no good use at all. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
: On Thu, Dec 05, 2013 at 09:12:30AM -0800, Roy Smith wrote: > I keep hearing that I should use gmane as a superior interface. Well, > I tried that. I went to http://dir.gmane.org/search.php, where it > asks me to search for a newsgroup. I type in "comp.lang.python", and > it tells me, "No matching groups". So, that seems pretty broken to > me. That's not entirely fair - Gmane presents mailing lists as newsgroups, not vice versa, so it doesn't know that [email protected] is connected to comp.lang.python (or that comp.lang.python even exists). A search for the mailing list from the front page works just fine: http://gmane.org/find.php?list=python-list%40python.org -[]z. -- Zero Piraeus: flagellum dei http://etiol.net/pubkey.asc -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On 05/12/2013 17:50, Zero Piraeus wrote: : On Thu, Dec 05, 2013 at 09:12:30AM -0800, Roy Smith wrote: I keep hearing that I should use gmane as a superior interface. Well, I tried that. I went to http://dir.gmane.org/search.php, where it asks me to search for a newsgroup. I type in "comp.lang.python", and it tells me, "No matching groups". So, that seems pretty broken to me. That's not entirely fair - Gmane presents mailing lists as newsgroups, not vice versa, so it doesn't know that [email protected] is connected to comp.lang.python (or that comp.lang.python even exists). A search for the mailing list from the front page works just fine: http://gmane.org/find.php?list=python-list%40python.org -[]z. Another useful link, there are just a few python goodies there http://news.gmane.org/index.php?prefix=gmane.comp.python -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On 2013-12-05 17:50, Zero Piraeus wrote: : On Thu, Dec 05, 2013 at 09:12:30AM -0800, Roy Smith wrote: I keep hearing that I should use gmane as a superior interface. Well, I tried that. I went to http://dir.gmane.org/search.php, where it asks me to search for a newsgroup. I type in "comp.lang.python", and it tells me, "No matching groups". So, that seems pretty broken to me. That's not entirely fair - Gmane presents mailing lists as newsgroups, not vice versa, so it doesn't know that [email protected] is connected to comp.lang.python (or that comp.lang.python even exists). A search for the mailing list from the front page works just fine: http://gmane.org/find.php?list=python-list%40python.org Right. GMane is an NNTP service, but it is not part of the USENET network. comp.lang.python is a USENET newsgroup and requires a true USENET server (not just an NNTP server) to access. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: status of regex modules
On 05/12/2013 04:37, Terry Reedy wrote: On 12/4/2013 11:21 AM, Mark Lawrence wrote: On 24/10/2013 22:47, Mark Lawrence wrote: The new module is now five years old. PEP 429 Python 3.4 release schedule has it listed under "Other proposed large-scale changes" but I don't believe this is actually happening. Lots of issues on the bug tracker have been closed as fixed in the new module, see issue 2636 for more data. Some work is still being carried out on the old re module. So where do we stand? Is the new module getting into Python 3.x, Python 4.y or what? Good question. I hope so. So do I. When? is the simple question that I'd like to see answered. If no do all the old issues have to be reopened and applied to the re module? I would prefer not. So would I, but it's already been deffered twice (see below), wash rinse, repeat? So should it again fail to be accepted into the Python core for 3.5, will there be a sensible alternative to doing precisely this? Who has to make the final decision on all of this? Ultimately Guido, with a lot of input I assume that Guido could now delegate this if he wished, in the same way that PEPs are now delegated? Note that I've no direct interest as I rarely if ever use the little perishers, I just find this situation bizarre. It is definitely unfortunate and even embarrassing. At one time, the hangup was a minor feature incompatibility between re and regex. Guido was reluctant to make a switch that would occasionally break code. I believe that this is fixed -- by deciding to call it regex rather then re. A definite pig's ear, but one that has been shaped by history. It's my belief that it's now too late to go back and write a PEP for all the changes as would certainly be required now, so let's take this forward. I do not know enough about the hangup or name change to comment. My impression from http://bugs.python.org/issue2636 Stage: patch review and pydev discussion is that regex did not land in 3.4 because no one did the rest of the needed review. I do not really know what needs to be done next. Being coded in C does not help speed review. I don't recall seeing any discussion about it getting into 3.4, did I miss something? Previously it didn't get into 3.3 either, see http://www.python.org/dev/peps/pep-0398/ Python 3.3 Release Schedule, where it's listed in the section "Deferred to post-3.3:". And FTR I'll break Armed Forces Rule No. 1 and volunteer my own pitifully poor servies if I can help take this forward, as I think it's daft having issues marked as fixed on the bug tracker but the fix not being available in the standard library, only on pypi. Are you volunteering to list issues to be reopened, or to help with code review? I don't mind doing any grunt work to help out. I am not qualified to take on code review for a high profile Python module that is written in C. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Official discussion forum for a project (was: Packaging a proprietary Python library for multiple OSs)
Travis Griggs writes: > On Dec 5, 2013, at 2:56 AM, rusi wrote: > > > 3. https://groups.google.com/forum/#!forum/python-virtualenv may be > > a better place to ask > > Am I the only one that sees the irony in this suggestion? Given the > long running tirades^H^H^H^H^H^H thread about “Managing Google Groups > headaches”? In addition to the fact that “rusi” evidently does not hold that position, the Virtualenv project http://www.virtualenv.org/> has its official discussion forum hosted at Google Groups, and the above quote merely points that out. One can recommend strongly against Google Groups in general as a dreadful service, while still directing people to the official discussion forum for a particular project which has made the (to whatever degree misguided) decision to use that service. -- \ “Simplicity and elegance are unpopular because they require | `\ hard work and discipline to achieve and education to be | _o__)appreciated.” —Edsger W. Dijkstra | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
PIL(Pillow) fails with PNG image
Hi, I am getting an error when trying to use Pillow library to display
image PNG on a Tkinter Button widget. Here is my code.
|image= Image.open(os.path.join('icons','bulb.png')) # using PIL for png
images
self.correctGuessImage= ImageTk.PhotoImage(image)
|>>>
|File "/home/user/Documents/temp.py", line222, in drawButtons
self.correctGuessImage= ImageTk.PhotoImage(image)
File "/usr/lib/python2.7/dist-packages/PIL/ImageTk.py", line121, in
__init__
self.paste(image)
File "/usr/lib/python2.7/dist-packages/PIL/ImageTk.py", line171, in paste
im.load()
File "/usr/lib/python2.7/dist-packages/PIL/ImageFile.py", line192, in load
d= Image._getdecoder(self.mode, d, a, self.decoderconfig)
AttributeError: 'module' object has no attribute'_getdecoder'|||
While working fine under windows 7x64 it fails to work on Linux Mint
x64. I am getting this error running the same file. I installed
everything I could find with 'python','png' and 'tk' from the reps but
no effect. Any ideas why is this happening and how to fix this?
Pavel
--
https://mail.python.org/mailman/listinfo/python-list
Re: PIL(Pillow) fails with PNG image
I cannot answer your question, but wanted to mention that you should
send text only and not include an html copy of messages.
On 12/5/2013 3:26 PM, tastyminerals wrote:
Hi, I am getting an error when trying to use Pillow library to display
image PNG on a Tkinter Button widget. Here is my code.
|image= Image.open(os.path.join('icons','bulb.png')) # using PIL for png
images
self.correctGuessImage= ImageTk.PhotoImage(image)
|>>>
|File "/home/user/Documents/temp.py", line222, in drawButtons
self.correctGuessImage= ImageTk.PhotoImage(image)
File "/usr/lib/python2.7/dist-packages/PIL/ImageTk.py", line121, in
__init__
self.paste(image)
File "/usr/lib/python2.7/dist-packages/PIL/ImageTk.py", line171, in paste
im.load()
File "/usr/lib/python2.7/dist-packages/PIL/ImageFile.py", line192, in
load
d= Image._getdecoder(self.mode, d, a, self.decoderconfig)
AttributeError: 'module' object has no attribute'_getdecoder'|||
While working fine under windows 7x64 it fails to work on Linux Mint
x64. I am getting this error running the same file. I installed
everything I could find with 'python','png' and 'tk' from the reps but
no effect. Any ideas why is this happening and how to fix this?
Pavel
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: PIL(Pillow) fails with PNG image
In tastyminerals writes: > d= Image._getdecoder(self.mode, d, a, self.decoderconfig) > AttributeError: 'module' object has no attribute'_getdecoder'||| Do you have your own module named Image.py? -- John Gordon Imagine what it must be like for a real medical doctor to [email protected] 'House', or a real serial killer to watch 'Dexter'. -- https://mail.python.org/mailman/listinfo/python-list
Embedding multiple interpreters
Hi!
I hope I've got the right list here- there were a few to choose from. :}
I am trying to embed Python with multiple interpreters into an existing
application. I have things working fine with a single interpreter thus
far. I am running into problems when using multiple interpreters [1] and
I am presently trying to track down these issues. Can anyone familiar
with the process of embedding multiple interpreters have a skim of the
details below and let me know of any obvious problems? If I can get the
essentials right, then presumably it's just a matter of my tracking down
any problems with my code.
I am presently using Python 3.3.3.
What I am after:
- Each sub-interpreter will have its own dedicated thread. Each thread
will have no more than one sub-interpreter. Basically, there is a
one-to-one mapping between threads and interpreters (some threads are
unrelated to Python though).
- The default interpreter in the main thread will never be used,
although I can explicitly use it if it'll help in some way.
- Each thread is created and managed outside of Python. This can't be
readily changed.
- I have a single internal module I need to be able to use for each
interpreter.
- I load scripts into __main__ and create objects from it to bootstrap.
- I understand that for the most part only a single interpreter will be
running at a time due to the GIL. This is unfortunate but not a major
problem.
- I don't need to share objects between interpreters (if it is even
possible- I don't know).
- My fallback if I can't do this is to implement each instance in a
dedicated *process* rather than per-thread. However, there is a
significant cost to doing this that I would rather not incur.
Could I confirm:
- There is one GIL in a given process, shared amongst all (sub)
interpreters. There seems some disagreement on this one online, although
I'm fairly confident that there is only the one GIL.
- I am using the mod_wsgi source for inspiration. Is there a better
source for an example of embedding multiple interpreters?
A query re the doco:
http://docs.python.org/3/c-api/init.html#gilstate
"Python supports the creation of additional interpreters (using
Py_NewInterpreter()), but mixing multiple interpreters and the
PyGILState_*() API is unsupported."
Is this actually correct? mod_wsgi seems to do it. Have I misunderstood?
I've extracted what I have so far from my code into a form that can be
followed more easily. Hopefully I have not made any mistakes in doing
so. The essence of what my code calls should be as follows:
=== Global init, run once:
static PyThreadState *mtstate = NULL;
PyImport_AppendInittab("myinternalmodule", PyInit_myinternalmodule);
Py_SetProgramName((wchar_t *)"foo");
Pu_InitializeEx(0);
PyEval_InitThreads();
mtstate = PyThreadState_Get();
PyEval_ReleaseThread(mtstate);
=== Global shutdown, run once at end:
Py_Finalize();
=== Per-interpreter init in main thread before launching child thread:
(none thus far)
=== Init in dedicated thread for each interpreter:
// NB: Also protected by a single global non-Python mutex to be sure.
PyGILState_STATE gil = PyGILState_Ensure();
PyThreadState *save_tstate = PyThreadState_Swap(NULL);
state = Py_NewInterpreter();
PyThreadState_Swap(save_tstate);
PyObject *mmodule = PyImport_AddModule("__main__");
Py_INCREF(mmodule);
PyImport_ImportModule("myinternalmodule");
PyGILState_Release(gil);
=== Shutdown in dedicated thread for each interpreter:
// NB: Also protected by the same single global non-Python mutex as in
the init.
PyGILState_STATE gil = PyGILState_Ensure();
PyThreadState *save_tstate = PyThreadState_Swap(state);
Py_EndInterpreter(state);
PyThreadState_Swap(save_tstate);
PyGILState_Release(gil);
=== Placed at top of scope where calls made to Python C API:
SafeLock lock;
=== SafeLock implementation:
class SafeLock
{
public:
SafeLock() {gil = PyGILState_Ensure();}
~SafeLock() {PyGILState_Release(gil);}
private:
PyGILState_STATE gil;
};
===
Does this look roughly right? Have I got the global and per-interpreter
init and shutdown right? Am I locking correctly in SafeLock- is
PyGILState_Ensure() and PyGILState_Release() sufficient?
Is there an authoritative summary of the global and per-interpreter init
and shutdown somewhere that I have missed? Any resource I should be reading?
Cheers,
Garth
[1] It presently crashes in Py_EndInterpreter() after running through a
series of tests during the shutdown of the 32nd interpreter I create. I
don't know if this is significant, but the tests pass for the first 31
interpreters.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Recursive generator for combinations of a multiset?
On Wed, Nov 20, 2013 at 10:46 PM, John O'Hagan wrote: > > Short story: the subject says it all, so if you have an answer already, > fire away. Below is the long story of what I'm using it for, and why I > think it needs to be recursive. It may even be of more general > interest in terms of filtering the results of generators. > > Any suggestions? > I've updated my code at http://stromberg.dnsalias.org/svn/anagrams/trunk/; It's multiword now. It can blast through the word "punishment" in 4 seconds, but for "The public art galleries" it ate about 7 gigabytes of RAM and ran for more than a day before I killed it. I believe it's an exponential problem. Parallelization might help, but it'd probably take a lot of RAM that way. Maybe the RAM use would be better with CPython, but it's much faster with Pypy; I did most of my testing with Pypy 2.2. -- https://mail.python.org/mailman/listinfo/python-list
Re: Embedding multiple interpreters
On 12/05/2013 07:34 PM, Garthy wrote: > - My fallback if I can't do this is to implement each instance in a > dedicated *process* rather than per-thread. However, there is a > significant cost to doing this that I would rather not incur. What cost is this? Are you speaking of cost in terms of what you the programmer would have to do, cost in terms of setting things up and communicating with the process, or the cost of creating a process vs a thread? If it's the last, on most modern OS's (particularly Linux), it's really not that expensive. On Linux the cost of threads and processes are nearly the same. -- https://mail.python.org/mailman/listinfo/python-list
Re: Embedding multiple interpreters
On Fri, Dec 6, 2013 at 4:16 PM, Michael Torrie wrote: > On 12/05/2013 07:34 PM, Garthy wrote: >> - My fallback if I can't do this is to implement each instance in a >> dedicated *process* rather than per-thread. However, there is a >> significant cost to doing this that I would rather not incur. > > What cost is this? Are you speaking of cost in terms of what you the > programmer would have to do, cost in terms of setting things up and > communicating with the process, or the cost of creating a process vs a > thread? If it's the last, on most modern OS's (particularly Linux), > it's really not that expensive. On Linux the cost of threads and > processes are nearly the same. If you want my guess, the cost of going to multiple processes would be to do with passing data back and forth between them. Why is Python being embedded in another application? Sounds like there's data moving from C to Python to C, ergo breaking that into separate processes means lots of IPC. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: using ffmpeg command line with python's subprocess module
在 2013年12月4日星期三UTC+8下午5时38分27秒，Andreas Perstinger写道：
> iMath wrote:
>
> >I use the following code to do the test ,but error occurred ,it
>
> >prompts system cannot find specified files ,but the files are indeed
>
> >exists there ,any help ?
>
> >
>
> >with tempfile.TemporaryFile() as fp:
>
> >fp.write(("file '"+'a1.mp3'+"'\n").encode('utf-8'))
>
> >fp.write(("file '"+'a2.mp3'+"'\n").encode('utf-8'))
>
> >
>
> >subprocess.call(['ffmpeg/ffmpeg', '-f', 'concat','-i',fp, '-c',
>
> > 'copy', 'a3.mp3'])
>
>
>
> Basic rule: Always copy'n'paste the exact traceback you get.
>
>
>
> I don't think you are running the code you have posted because your
>
> subprocess call doesn't work:
>
>
>
> >>> import tempfile, subprocess
>
> >>> with tempfile.TemporaryFile() as fp:
>
> ... subprocess.call(["foo", "bar", fp, "baz"])
>
> ...
>
> Traceback (most recent call last):
>
> File "", line 2, in
>
> File "/usr/lib/python3.3/subprocess.py", line 520, in call
>
> with Popen(*popenargs, **kwargs) as p:
>
> File "/usr/lib/python3.3/subprocess.py", line 820, in __init__
>
> restore_signals, start_new_session)
>
> File "/usr/lib/python3.3/subprocess.py", line 1380, in _execute_child
>
> restore_signals, start_new_session, preexec_fn)
>
> TypeError: Can't convert '_io.BufferedRandom' object to str implicitly
>
>
>
> "fp" is a file object, but subprocess expects a list of strings as
>
> its first argument.
>
>
>
> Bye, Andreas
sorry for my fuss.
it prompts
StdErr: -c: No such file or directory
--
https://mail.python.org/mailman/listinfo/python-list
Re: PIL(Pillow) fails with PNG image
Am 05.12.13 21:26, schrieb tastyminerals:
Hi, I am getting an error when trying to use Pillow library to display
image PNG on a Tkinter Button widget. Here is my code.
|image= Image.open(os.path.join('icons','bulb.png')) # using PIL for png
images
self.correctGuessImage= ImageTk.PhotoImage(image)
I don't know what is the problem here, but Tk supports PNG natively from
8.5 onwards; just use
self.correctGuessImage= ImageTk.PhotoImage(file='bulb.png')
Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: Embedding multiple interpreters
Garthy wrote: I am running into problems when using multiple interpreters [1] and I am presently trying to track down these issues. Can anyone familiar with the process of embedding multiple interpreters have a skim of the details below and let me know of any obvious problems? As far as I know, multiple interpreters in one process is not really supported. There *seems* to be partial support for it in the code, but there is no way to fully isolate them from each other. Why do you think you need multiple interpreters, as opposed to one interpreter with multiple threads? If you're trying to sandbox the threads from each other and/or from the rest of the system, be aware that it's extremely difficult to securely sandbox Python code. You'd be much safer to run each one in its own process and rely on OS-level protections. - I understand that for the most part only a single interpreter will be running at a time due to the GIL. Yes, as far as I can tell, there is only one GIL in a given process. - I don't need to share objects between interpreters (if it is even possible- I don't know). The hard part is *not* sharing objects between interpreters. If nothing else, all the builtin type objects, constants, etc. will be shared. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Thursday, December 5, 2013 6:28:54 AM UTC+5:30, Roy Smith wrote: > Rich Kulawiec wrote: > > Yes, I'm > > aware of web forums: I've used hundreds of them. They suck. They ALL > > suck, they just all suck differently. I could spend the next several > > thousand lines explaining why, but instead I'll just abbreviate: they > > don't handle threading, they don't let me use my editor of choice, > > they don't let me build my own archive that I can search MY way including > > when I'm offline, they are brittle and highly vulnerable to abuse > > and security breaches, they encourage worst practices in writing > > style (including top-posting and full-quoting), they translate poorly > > to other formats, they are difficult to archive, they're even more > > difficult to migrate (whereas Unix mbox format files from 30 years ago > > are still perfectly usable today), they aren't standardized, they > > aren't easily scalable, they're overly complex, they don't support > > proper quoting, they don't support proper attribution, they can't > > be easily forwarded, they...oh, it just goes on. > The real problem with web forums is they conflate transport and > presentation into a single opaque blob, and are pretty much universally > designed to be a closed system. Mail and usenet were both engineered to > make a sharp division between transport and presentation, which meant it > was possible to evolve each at their own pace. > Mostly that meant people could go off and develop new client > applications which interoperated with the existing system. But, it also > meant that transport layers could be switched out (as when NNTP > gradually, but inexorably, replaced UUCP as the primary usenet transport > layer). There is a deep assumption hovering round-about the above -- what I will call the 'Unix assumption(s)'. But before that, just a check on terminology. By 'presentation' you mean what people normally call 'mail-clients': thunderbird, mutt etc. And by 'transport' you mean sendmail, exim, qmail etc etc -- what normally are called 'mail-servers.' Right?? Assuming this is the intended meaning of the terminology (yeah its clearer terminology than the usual and yeah Im also a 'Unix-guy'), here's the 'Unix-assumption': - human communication… (is not very different from) - machine communication… (can be done by) - text… (for which) - ASCII is fine… (which is just) - bytes… (inside/between byte-memory-organized) - von Neumann computers To the extent that these assumptions are invalid, the 'opaque-blob' may well be preferable. -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
In article <[email protected]>, rusi wrote: > On Thursday, December 5, 2013 6:28:54 AM UTC+5:30, Roy Smith wrote: > > The real problem with web forums is they conflate transport and > > presentation into a single opaque blob, and are pretty much universally > > designed to be a closed system. Mail and usenet were both engineered to > > make a sharp division between transport and presentation, which meant it > > was possible to evolve each at their own pace. > > > Mostly that meant people could go off and develop new client > > applications which interoperated with the existing system. But, it also > > meant that transport layers could be switched out (as when NNTP > > gradually, but inexorably, replaced UUCP as the primary usenet transport > > layer). > > There is a deep assumption hovering round-about the above -- what I > will call the 'Unix assumption(s)'. It has nothing to do with Unix. The separation of transport from presentation is just as valid on Windows, Mac, etc. > But before that, just a check on > terminology. By 'presentation' you mean what people normally call > 'mail-clients': thunderbird, mutt etc. And by 'transport' you mean > sendmail, exim, qmail etc etc -- what normally are called > 'mail-servers.' Right?? Yes. > Assuming this is the intended meaning of the terminology (yeah its > clearer terminology than the usual and yeah Im also a 'Unix-guy'), > here's the 'Unix-assumption': > > - human communication > (is not very different from) > - machine communication > (can be done by) > - text > (for which) > - ASCII is fine > (which is just) > - bytes > (inside/between byte-memory-organized) > - von Neumann computers > > To the extent that these assumptions are invalid, the 'opaque-blob' > may well be preferable. I think you're off on the wrong track here. This has nothing to do with plain text (ascii or otherwise). It has to do with divorcing how you store and transport messages (be they plain text, HTML, or whatever) from how a user interacts with them. Take something like Wikipedia (by which, I really mean, MediaWiki, which is the underlying software package). Most people think of Wikipedia as a web site. But, there's another layer below that which lets you get access to the contents of articles, navigate all the rich connections like category trees, and all sorts of metadata like edit histories. Which means, if I wanted to (and many examples of this exist), I can write my own client which presents the same information in different ways. -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Thursday, December 5, 2013 4:17:11 AM UTC+5:30, Cameron Simpson wrote: > On 03Dec2013 17:39, rusi wrote: > > On Wednesday, December 4, 2013 6:10:05 AM UTC+5:30, Cameron Simpson wrote: > > > My first act on joining any mailing list is to download the entire > > > archive into my local mail store. I have a script for this, for > > > mailman at least. > > and you happen to own >1 thingys that have general computing > > functionality -- phones, laptops, desktops, etc -- do you sync > > all your mailing-lists with all of them? > No. I'm using a laptops my primary host, and it has the mailing > lists (and all my email). It is usually on and fetches and files > my email; it also forwards _specific_ stuff to a separate mail > account accessed by my phone. > I used to use a home server, but the remote access, while fairly > transparent (script to "ssh then run mutt"), was irritating. And > when I didn't have remote access, very very irritating. > So I'm choosing the better environment with my email local to the laptop and > a select copy of important things (work and friends) copied to an account for > my phone. > [...] > > And inspite of all that it still sometimes happens that one has > > to work on a 'machine' that is not one's own. What then? > Fingers crossed the important stuff gets to my phone. If urgent I > can reply from that, and I'm somewhat up to date on what I care > about. The phone also has (disabled) access to my primary mail spool > for circumstances when the laptop is offline. When online, the > laptop empties that spool ad forwards particulars. When offline, I > can consult what's queuing up. > > The unfortunate and inexorable conclusion is that when the > > (wo)man <-> computer relation goes from 1-1 to 1-many, data and > > functionality will move away from 'own-machine' to the cloud. > > Will the data be subject to privacy-abuse and worse? Sure > > Will the functionality be as good as something one can fine-tune > > on one's own computer? heck no! > I'm striving to resist that for now. Privacy. Security. Dependence > on others' hardware and (not mine => wrong!) technical choices of > software. Thanks Cameron. I am not sure how to parse the last sentence but on the whole thanks for a fair balanced and honest review. I think I have similar sentiments, viz. I am not one to gush about the latest gizmodic blissiness, however whenever Ive resisted and been a late adopter -- color monitor, laptop, cellphone, credit card etc etc -- in the end Ive had to move with the time and not been better-off for my earlier resistance. -- https://mail.python.org/mailman/listinfo/python-list
