From rustompmody at gmail.com Sun Jun 1 00:11:12 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Sat, 31 May 2014 21:11:12 -0700 (PDT) Subject: Python 3 is killing Python In-Reply-To: References: <57ajo9poljjre4c4ig0n0ss8kph8k78lp0@4ax.com> <965lo9tqov049ldm9jlgukcchjonnh1m50@4ax.com> Message-ID: On Sunday, June 1, 2014 9:05:11 AM UTC+5:30, Chris Angelico wrote: > So if you want to start a one-man airline (where you're managing the > company, flying the plane, and everything else), do you start by > looking at the relative merits of the 747-400 and 777-300ER I guess a person starting a one-man airline would be choosing a 7-15 seater and doing short to medium runs. Are there 7[47]7's in 7-15 seater range ? And the earlier description of the choice for Word 97 reminded me of one of the 'prophet's' quotes from Illusions: <> [Disclaimer: I was a Richard Bach fan in my youth] From bob.martin at excite.com Sun Jun 1 07:01:46 2014 From: bob.martin at excite.com (Bob Martin) Date: Sun, 01 Jun 2014 07:01:46 BST Subject: Python 3 is killing Python References: <57ajo9poljjre4c4ig0n0ss8kph8k78lp0@4ax.com> <965lo9tqov049ldm9jlgukcchjonnh1m50@4ax.com> Message-ID: in 722929 20140601 035727 Steve Hayes wrote: >No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer >may be later and more technically advanced and flew faster, but no one uses or >supports it. Actually, the Concorde preceded the 747, and wasn't as "technically advanced", it was just faster. From breamoreboy at yahoo.co.uk Sun Jun 1 02:52:47 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Sun, 01 Jun 2014 07:52:47 +0100 Subject: Python 3 is killing Python In-Reply-To: References: <57ajo9poljjre4c4ig0n0ss8kph8k78lp0@4ax.com> <965lo9tqov049ldm9jlgukcchjonnh1m50@4ax.com> Message-ID: On 01/06/2014 07:01, Bob Martin wrote: > in 722929 20140601 035727 Steve Hayes wrote: > >> No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer >> may be later and more technically advanced and flew faster, but no one uses or >> supports it. > > Actually, the Concorde preceded the 747, and wasn't as "technically advanced", > it was just faster. > I recall Barnes Wallis slagging off the droop nose, but what did he know about aircraft? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From wxjmfauth at gmail.com Sun Jun 1 03:38:49 2014 From: wxjmfauth at gmail.com (wxjmfauth at gmail.com) Date: Sun, 1 Jun 2014 00:38:49 -0700 (PDT) Subject: IDE for python In-Reply-To: References: <8761kozg98.fsf@rudin.co.uk> <7deeb0f8-f4f4-4661-b0bb-f9481b6ef35a@googlegroups.com> <878upjwewt.fsf@elektro.pacujo.net> <7713af25-2ed4-49b3-9457-b352f9486c78@googlegroups.com> Message-ID: <5607ad87-599e-424b-add8-6899ef219516@googlegroups.com> Le dimanche 1 juin 2014 03:48:07 UTC+2, Rustom Mody a ?crit?: > On Friday, May 30, 2014 10:37:00 PM UTC+5:30, Rustom Mody wrote: > > > > > You are talking about the infrastructure needed for writing unicode apps. > > > The language need not have non-ASCII lexemes for that > > > > > I am talking about something quite different. > > > Think for example of a German wanting to write "G?del" > > > According to some conventions (s)he can write Goedel > > > But if that is forced just because of ASCII/US-104/what-have-u it would justifiably > > > cause irritation/offense. > > > > Curiously I just saw this tex/emacs question/answer elsewhere ? > > particularly amusing the first 'char' of the answer. > > > > Question: > > | I'm a new Emacs/Auctex User. Auctex for Emacs is amazing but > > | there are some little things could be better. When generating a > > | section with c-c c-s the label ist generated automatically. But > > | if there is an german Umlaut in the section title like '?' this > > | becomes just 'a' in the label. Is there any possibility that > > | auctex will substitute the '?' by 'ae' and not by 'a'? > > > > Answer: > > | '?' is not possible, since latex can not handle Umlauts in references. > > | For 'ae' I'm sure someone is able to provide a little patch. %%%%%%%%%% \begin{document} """ A small text, ???. {\label{?tiquette??}}\\ See page \pageref{?tiquette??}. """ \end{document} >>> # copy/paste from the generated pdf in my interactive >>> # interpreter. >>> """ A small text, ???. ... See page 1. """ ' A small text, ???.\nSee page 1. ' >>> jmf From marko at pacujo.net Sun Jun 1 03:58:35 2014 From: marko at pacujo.net (Marko Rauhamaa) Date: Sun, 01 Jun 2014 10:58:35 +0300 Subject: IDE for python References: <8761kozg98.fsf@rudin.co.uk> <7deeb0f8-f4f4-4661-b0bb-f9481b6ef35a@googlegroups.com> <878upjwewt.fsf@elektro.pacujo.net> <7713af25-2ed4-49b3-9457-b352f9486c78@googlegroups.com> Message-ID: <87lhth9i38.fsf@elektro.pacujo.net> Rustom Mody : > On Friday, May 30, 2014 10:37:00 PM UTC+5:30, Rustom Mody wrote: >> Think for example of a German wanting to write "G?del" >> According to some conventions (s)he can write Goedel > > [...] > > | if there is an german Umlaut in the section title like '?' this > | becomes just 'a' in the label. Is there any possibility that auctex > | will substitute the '?' by 'ae' and not by 'a'? > > Answer: > | '?' is not possible, since latex can not handle Umlauts in > | references. For 'ae' I'm sure someone is able to provide a little > | patch. As a Finnish-speaker, I hope that patch doesn't become default behavior. Too many times, we have been victimized by the German conventions. A Finnish-speaker would much rather see J?rvenp?? => Jarvenpaa ?ll?l? => Ollola K?rkk?inen => Karkkainen than J?rvenp?? => Jaervenpaeae ?ll?l? => Oelloelae K?rkk?inen => Kaerkkaeinen Marko From rosuav at gmail.com Sun Jun 1 04:31:09 2014 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 1 Jun 2014 18:31:09 +1000 Subject: IDE for python In-Reply-To: <87lhth9i38.fsf@elektro.pacujo.net> References: <8761kozg98.fsf@rudin.co.uk> <7deeb0f8-f4f4-4661-b0bb-f9481b6ef35a@googlegroups.com> <878upjwewt.fsf@elektro.pacujo.net> <7713af25-2ed4-49b3-9457-b352f9486c78@googlegroups.com> <87lhth9i38.fsf@elektro.pacujo.net> Message-ID: On Sun, Jun 1, 2014 at 5:58 PM, Marko Rauhamaa wrote: > As a Finnish-speaker, I hope that patch doesn't become default behavior. > Too many times, we have been victimized by the German conventions. A > Finnish-speaker would much rather see > > J?rvenp?? => Jarvenpaa > ?ll?l? => Ollola > K?rkk?inen => Karkkainen > > than > > J?rvenp?? => Jaervenpaeae > ?ll?l? => Oelloelae > K?rkk?inen => Kaerkkaeinen It's even worse than that. The rules for ASCIIfying adorned characters vary according to context - M?ller and Mueller are different names, and in many contexts should sort and compare differently, and I remember reading somewhere that there's a context in which it's more useful to decompose ? to u rather than ue. There is no "safe" lossy transformation that can be done to any language's words, and this is no exception. ASCIIfication has to be accepted as flawed; this issue (an inability to handle non-ASCII labels) is similar to a lot of blog URLs - http://rosuav.blogspot.com/2013/08/20th-international-g-festival-awards.html is talking about the "International G&S Festival" awards, but the URL drops the "&S" part. (If you absolutely have to transmit something losslessly in pure ASCII, you need a scheme like Punycode, which is a lot less clean and readable than a decomposition scheme.) Of course, the better solution is to permit the full Unicode alphabet in identifiers... ChrisA From rustompmody at gmail.com Sun Jun 1 04:52:29 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Sun, 1 Jun 2014 01:52:29 -0700 (PDT) Subject: IDE for python In-Reply-To: References: <8761kozg98.fsf@rudin.co.uk> <7deeb0f8-f4f4-4661-b0bb-f9481b6ef35a@googlegroups.com> <878upjwewt.fsf@elektro.pacujo.net> <7713af25-2ed4-49b3-9457-b352f9486c78@googlegroups.com> <87lhth9i38.fsf@elektro.pacujo.net> Message-ID: On Sunday, June 1, 2014 2:01:09 PM UTC+5:30, Chris Angelico wrote: > On Sun, Jun 1, 2014 at 5:58 PM, Marko Rauhamaa wrote: > > As a Finnish-speaker, I hope that patch doesn't become default behavior. > > Too many times, we have been victimized by the German conventions. A > > Finnish-speaker would much rather see > > J?rvenp?? => Jarvenpaa > > ?ll?l? => Ollola > > K?rkk?inen => Karkkainen > > than > > J?rvenp?? => Jaervenpaeae > > ?ll?l? => Oelloelae > > K?rkk?inen => Kaerkkaeinen > It's even worse than that. The rules for ASCIIfying adorned characters > vary according to context - M?ller and Mueller are different names, > and in many contexts should sort and compare differently, and I > remember reading somewhere that there's a context in which it's more > useful to decompose ? to u rather than ue. There is no "safe" lossy > transformation that can be done to any language's words, and this is > no exception. ASCIIfication has to be accepted as flawed; this issue > (an inability to handle non-ASCII labels) is similar to a lot of blog > URLs - http://rosuav.blogspot.com/2013/08/20th-international-g-festival-awards.html > is talking about the "International G&S Festival" awards, but the URL > drops the "&S" part. (If you absolutely have to transmit something > losslessly in pure ASCII, you need a scheme like Punycode, which is a > lot less clean and readable than a decomposition scheme.) > Of course, the better solution is to permit the full Unicode alphabet > in identifiers... Yes that is the real point. Changing the current behavior which maps [?,??] ? [o,a?] to a new behavior that maps it to [oe,ae?], then arguing that this should/should not become default is the wrong battle. The more useful line is: Why have this conversion at all? Until hardly 3 years ago html authors wrote non-ASCII as chars as html entities. Now the current standard practice is directly to write the character and make sure the page is explicitly utf-8. Its only a question of time before this becomes standard practice in all domains From steve+comp.lang.python at pearwood.info Sun Jun 1 05:06:34 2014 From: steve+comp.lang.python at pearwood.info (Steven D'Aprano) Date: 01 Jun 2014 09:06:34 GMT Subject: IDE for python References: <8761kozg98.fsf@rudin.co.uk> <7deeb0f8-f4f4-4661-b0bb-f9481b6ef35a@googlegroups.com> <878upjwewt.fsf@elektro.pacujo.net> <7713af25-2ed4-49b3-9457-b352f9486c78@googlegroups.com> <87lhth9i38.fsf@elektro.pacujo.net> Message-ID: <538aed19$0$29978$c3e8da3$5496439d@news.astraweb.com> On Sun, 01 Jun 2014 18:31:09 +1000, Chris Angelico wrote: > the better solution is to permit the full Unicode alphabet in > identifiers... I'm not entirely sure about that. Full Unicode support in identifiers such as URLs doesn't create a brand new vulnerability, but it does increase it from a fairly minor problem to something *much* harder to deal with. It's bad enough when somebody manages to fool you into going to (say) app1e.com instead of apple.com, without also being at risk from ???l?, ?p?l?, ??pl? and ???le (to mention just a few). At least nobody can fake .com with .??m. To put it another way: py> ???l? = 23 py> apple = 42 py> assert ???l? == apple Traceback (most recent call last): File "", line 1, in AssertionError -- Steven From rosuav at gmail.com Sun Jun 1 05:59:36 2014 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 1 Jun 2014 19:59:36 +1000 Subject: IDE for python In-Reply-To: <538aed19$0$29978$c3e8da3$5496439d@news.astraweb.com> References: <8761kozg98.fsf@rudin.co.uk> <7deeb0f8-f4f4-4661-b0bb-f9481b6ef35a@googlegroups.com> <878upjwewt.fsf@elektro.pacujo.net> <7713af25-2ed4-49b3-9457-b352f9486c78@googlegroups.com> <87lhth9i38.fsf@elektro.pacujo.net> <538aed19$0$29978$c3e8da3$5496439d@news.astraweb.com> Message-ID: On Sun, Jun 1, 2014 at 7:06 PM, Steven D'Aprano wrote: > On Sun, 01 Jun 2014 18:31:09 +1000, Chris Angelico wrote: > >> the better solution is to permit the full Unicode alphabet in >> identifiers... > > I'm not entirely sure about that. Full Unicode support in identifiers > such as URLs doesn't create a brand new vulnerability, but it does > increase it from a fairly minor problem to something *much* harder to > deal with. It's bad enough when somebody manages to fool you into going > to (say) app1e.com instead of apple.com, without also being at risk from > ???l?, ?p?l?, ??pl? and ???le (to mention just a few). At least nobody > can fake .com with .??m. > > To put it another way: > > py> ???l? = 23 > py> apple = 42 > py> assert ???l? == apple > Traceback (most recent call last): > File "", line 1, in > AssertionError Yeah, that is a concern. But as you say, it's already possible to confuse rn with m (in many fonts) and i/l/1, and (on a different level) Foo, foo, _foo, _Foo, and FOO, or movement_Direction and movement_direction. If you saw one of those in one part of a program and another in another, you'd have to consume an annoying amount of mindspace to keep them separate. Note, incidentally, that I said "alphabet" rather than the entire Unicode character set. I do *not* support the use of, for instance, U+200B 'ZERO WIDTH SPACE' in identifiers, that's just stupid :) ChrisA From burak.arslan at arskom.com.tr Sun Jun 1 06:37:39 2014 From: burak.arslan at arskom.com.tr (Burak Arslan) Date: Sun, 01 Jun 2014 13:37:39 +0300 Subject: Suds and Python3 In-Reply-To: <538A2683.7050902@mcnettware.com> References: <7516fe94-db33-44ea-9586-92b7446324de@googlegroups.com> <538A2683.7050902@mcnettware.com> Message-ID: <538B0273.40701@arskom.com.tr> Hello, First, for such questions, there's always soap at python.org On 31/05/14 21:59, Paul McNett wrote: > On 5/31/14, 11:36 AM, tokibito at gmail.com wrote: >> Suds is defacto python SOAP client, but it does not mainte recent few >> years. Why? > The original authors don't seem to care anymore. If you search PyPi you'll see that there are many suds forks as a result. See e.g. https://pypi.python.org/pypi/suds-jurko/0.6 This was a popular topic during past month: https://mail.python.org/pipermail/soap/2014-May/thread.html > Is it really the defacto? It seems like I've heard more about > pysimplesoap, and looking at GitHub there have been commits in the > past 4 days. Yes, suds is really the de facto soap client for python. I'd even dropped the soap client in Spyne years ago in favor of suds. Seeing suds' current situation though, I'm more and more tempted to sit home one weekend and bring it back. > In general, SOAP has been falling out of favor over the past half > decade at least because of its relative heaviness next to, e.g. > RESTful web services usually using JSON instead of XML. Way, way > simpler and more fun to do. > Xml also has its strengths. Especially compared to json, which only supports 6 types: string, number, dict, list, boolean (true/false) and null. Json gets hairy very fast even when you try to do seemingly simple things like serializing arbitrary precision decimals. > And from what I can tell without actually trying any of them, > pysimplesoap feels like the best option currently. Not really, there are other options. See the discussions in the above link. Best, Burak From hayesstw at telkomsa.net Sun Jun 1 07:38:21 2014 From: hayesstw at telkomsa.net (Steve Hayes) Date: Sun, 01 Jun 2014 13:38:21 +0200 Subject: Python 3 is killing Python References: <57ajo9poljjre4c4ig0n0ss8kph8k78lp0@4ax.com> <965lo9tqov049ldm9jlgukcchjonnh1m50@4ax.com> Message-ID: On Sun, 1 Jun 2014 13:35:11 +1000, Chris Angelico wrote: >Boeing-List at Boeing.Org people, any hour of the day or night. All >you're doing is picking your technology on the basis of *one* >dead-tree book that you happen to have found. Is that really the most >important deciding point? Yes. -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk From hayesstw at telkomsa.net Sun Jun 1 07:41:33 2014 From: hayesstw at telkomsa.net (Steve Hayes) Date: Sun, 01 Jun 2014 13:41:33 +0200 Subject: Python 3 is killing Python References: <57ajo9poljjre4c4ig0n0ss8kph8k78lp0@4ax.com> <965lo9tqov049ldm9jlgukcchjonnh1m50@4ax.com> Message-ID: On Sun, 01 Jun 2014 07:01:46 BST, Bob Martin wrote: >in 722929 20140601 035727 Steve Hayes wrote: > >>No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer >>may be later and more technically advanced and flew faster, but no one uses or >>supports it. > >Actually, the Concorde preceded the 747, and wasn't as "technically advanced", >it was just faster. Boeing 747s were in airline service in 1970, Concorde didn't enter service till 4-5 years later. Not that it matters, it was just an analogy. I'm pretty certain that Python 2.x preceded Python 3.x -- Steve Hayes from Tshwane, South Africa Web: http://www.khanya.org.za/stevesig.htm Blog: http://khanya.wordpress.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk From breamoreboy at yahoo.co.uk Sun Jun 1 07:53:44 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Sun, 01 Jun 2014 12:53:44 +0100 Subject: Python 3 is killing Python In-Reply-To: References: <57ajo9poljjre4c4ig0n0ss8kph8k78lp0@4ax.com> <965lo9tqov049ldm9jlgukcchjonnh1m50@4ax.com> Message-ID: On 01/06/2014 12:41, Steve Hayes wrote: > On Sun, 01 Jun 2014 07:01:46 BST, Bob Martin wrote: > >> in 722929 20140601 035727 Steve Hayes wrote: >> >>> No, it's a bit like flying in a Boeing 747 rather than a Concorde. The latyer >>> may be later and more technically advanced and flew faster, but no one uses or >>> supports it. >> >> Actually, the Concorde preceded the 747, and wasn't as "technically advanced", >> it was just faster. > > Boeing 747s were in airline service in 1970, Concorde didn't enter service > till 4-5 years later. > > Not that it matters, it was just an analogy. I'm pretty certain that Python > 2.x preceded Python 3.x > Clearly you know nothing about the Python time machine :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From seyedfarzad.torabi at gmail.com Sun Jun 1 08:17:07 2014 From: seyedfarzad.torabi at gmail.com (Farzad Torabi) Date: Sun, 1 Jun 2014 05:17:07 -0700 (PDT) Subject: Drawing Sinus curve in Python Message-ID: Hi Experts I am trying to draw a sine curve in Python , well first I had a script that i could draw a function curve in this way : xMax = 25.0 points = [] for i in range(100): x = (float(i)/99)*xMax y = math.sqrt(x) points.append([x,y]) s.Spline(points=points) first i have questions that : what does the line x = (float(i)/99)*xMax do ? why do we multiply it by and then when I wanted to draw a sine curve I found this one : import math for angle in range(????): y = math.sin(math.radians(angle)) print(y) first , here instead of ???? can we put 2*pi ? second i wanted to try this method instead: xMax = pi Lamda = 200 points = [] for i in range(Lamda): x = (float(i)/99)*xMax y = math.sin(x) points.append([x,y]) it actually works much better and creates an actual sine curve but the lengths are not really what i want , also if i want to draw a straight line I use this command : xMax = 1 Lamda = 200 points = [] for i in range(Lamda): x = (float(i)/99) y = xMax points.append([x,y]) but then the problem will be that I can not control the length of this line and the sine curve , that should be equal From steve+comp.lang.python at pearwood.info Sun Jun 1 10:53:41 2014 From: steve+comp.lang.python at pearwood.info (Steven D'Aprano) Date: 01 Jun 2014 14:53:41 GMT Subject: Drawing Sinus curve in Python References: Message-ID: <538b3e75$0$29978$c3e8da3$5496439d@news.astraweb.com> On Sun, 01 Jun 2014 05:17:07 -0700, Farzad Torabi wrote: > Hi Experts > > I am trying to draw a sine curve in Python , well first I had a script > that i could draw a function curve in this way : > > xMax = 25.0 > points = [] > for i in range(100): > x = (float(i)/99)*xMax > y = math.sqrt(x) > points.append([x,y]) > > s.Spline(points=points) What is s? Where does it come from? > first i have questions that : what does the line x = (float(i)/99)*xMax > do ? why do we multiply it by In older versions of Python, division / with integer arguments does integer division, like C, instead of calculator division. For example: 1/2 => returns 0 instead of 1/2 returning 0.5 like a calculator does. In these older versions of Python, you can fix that by converting one of the arguments to a float first: 1/2.0 => 0.5 So "float(i)/99" converts the loop index i to a float, then divides by 99. An easier way to get the same result is "i/99.0". Then, multiplying by xMax simply scales the result to be between 0 and xMax, in this case 25.0. Look at the results: when i = 0, x = 0/99.0*25 = 0.0 when i = 99, x = 99/99.0*25.9 = 25.0 every other value of i gives a corresponding value between 0 and 25. > and then when I wanted to draw a sine curve I found this one : > > import math > > for angle in range(????): > y = math.sin(math.radians(angle)) > print(y) > > first , here instead of ???? can we put 2*pi ? No. The Python built-in range() function only accepts integer values. It is quite tricky to *accurately* produce floating point ranges. While it is easy to make a floating point range, it is much harder to make it accurate. You can see some discussion about the problem, and some sample code, here: http://code.activestate.com/recipes/577068 http://code.activestate.com/recipes/577878 http://code.activestate.com/recipes/577881 > second i wanted to try this method instead: > > xMax = pi > Lamda = 200 > points = [] > for i in range(Lamda): > x = (float(i)/99)*xMax > y = math.sin(x) > points.append([x,y]) > > it actually works much better and creates an actual sine curve but the > lengths are not really what i want , also if i want to draw a straight > line I use this command : > > xMax = 1 > Lamda = 200 > points = [] > for i in range(Lamda): > x = (float(i)/99) > y = xMax > points.append([x,y]) In this example, you are calculating points from a straight line. x varies from 0.0 to 2.0202 in steps of 1/99, and y is always the same value, 1. > but then the problem will be that I can not control the length of this > line and the sine curve , that should be equal You have to get the maths right, otherwise the graph will be wrong. -- Steven D'Aprano http://import-that.dreamwidth.org/ From mail at timgolden.me.uk Sun Jun 1 12:31:04 2014 From: mail at timgolden.me.uk (Tim Golden) Date: Sun, 01 Jun 2014 17:31:04 +0100 Subject: Command prompt not shown when running Python script with subprocess on Windows In-Reply-To: References: <29c26176-b573-4ac9-bf41-a18a53d7dfb9@googlegroups.com> <53856F53.5010303@timgolden.me.uk> Message-ID: <538B5548.9030801@timgolden.me.uk> 29/05/2014 20:21, ps16thypresenceisfullnessofjoy at gmail.com wrote: > That's interesting, now I learned something else too. As I said > before, though, I want users to be able to enter paths in the XML > file exactly the way they would be entered in a Windows shortcut. [...] > Since in a Windows shortcut you don't need to put quotes around a > path that doesn't contain spaces, I want to follow that behavior in > my program as well. [...] > So I guess I'll still have to do my "shlex dance" (which for some > reason I keep on mistyping as "shlex dane" :-)) unless I can learn a > better way to do it. It looks like it. Sometimes the behaviour out of the box just doesn't cut it. Don't forget, also, that you can subclass, eg, the shlex.shlex class and tweak it to do what you need. > > Also, is my calling os.path.expandvars only on the first argument a > good idea? I want to accept environment variables in my program, but > I don't want to call os.path.expandvars on all the arguments, because > I want to let other programs take care of parsing their own > arguments. I'd say that's a call only you can make given what you know of your requirements. That said, I'm not sure what the "other programs" are going to do with any embedded env vars except to expand them as you're doing. Ultimately, don't tie yourselves in knots either trying too hard to emulate Windows shortcuts or trying too hard to use shlex.split out of the box. Decide what constitutes a useful combination of features and implement them as simply as you can. [He says, winning the prize for stating the obvious :) ] TJG From alister.nospam.ware at ntlworld.com Sun Jun 1 13:21:24 2014 From: alister.nospam.ware at ntlworld.com (alister) Date: Sun, 01 Jun 2014 17:21:24 GMT Subject: Python 3 is killing Python References: <57ajo9poljjre4c4ig0n0ss8kph8k78lp0@4ax.com> <965lo9tqov049ldm9jlgukcchjonnh1m50@4ax.com> Message-ID: On Sun, 01 Jun 2014 13:41:33 +0200, Steve Hayes wrote: > On Sun, 01 Jun 2014 07:01:46 BST, Bob Martin > wrote: > >>in 722929 20140601 035727 Steve Hayes wrote: >> >>>No, it's a bit like flying in a Boeing 747 rather than a Concorde. The >>>latyer may be later and more technically advanced and flew faster, but >>>no one uses or supports it. >> >>Actually, the Concorde preceded the 747, and wasn't as "technically >>advanced", >>it was just faster. > > Boeing 747s were in airline service in 1970, Concorde didn't enter > service till 4-5 years later. > Concord first flight march 2 1969 757 First flight Feb 9 1969 so there is not actually that much in it 747 entered service much sooner however > Not that it matters, it was just an analogy. I'm pretty certain that > Python 2.x preceded Python 3.x -- There seems no plan because it is all plan. -- C.S. Lewis From ernest.bonat at gmail.com Sun Jun 1 13:37:24 2014 From: ernest.bonat at gmail.com (Ernest Bonat, Ph.D.) Date: Sun, 1 Jun 2014 10:37:24 -0700 Subject: Is MVC Design Pattern good enough? Message-ID: Hi All, I had developed many database business applications using MVC design pattern with different programming languages like PHP, Java EE, VB.NET, C#, VB 6.0, VBA, etc. All of them defined the Model layer as the data management of the application domain and business logic implementation. I ready don?t understand what the data has to do with applications business logic. Nothing? Can we implement the application business logic in another layer? Yes or no? Why? Explain? Thank you all for the inputs! -- Thanks Ernest Bonat, Ph.D. Senior Software Engineer Senior Business Statistics Analyst Mobile: 503.730.4556 Email: ernest.bonat at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at tombstonezero.net Sun Jun 1 14:39:38 2014 From: dan at tombstonezero.net (Dan Sommers) Date: Sun, 1 Jun 2014 18:39:38 +0000 (UTC) Subject: [OT] Re: Is MVC Design Pattern good enough? References: Message-ID: On Sun, 01 Jun 2014 10:37:24 -0700, Ernest Bonat, Ph.D. wrote: > ... MVC design pattern ... defined the Model layer as the data > management of the application domain and business logic implementation > ... Can we implement the application business logic in another layer? > Yes or no? Why? Explain? This is not a Python-specific question, but as far as I'm concerned, you can certainly add structure, modularity, testability, maintainability, readability, flexibility, etc. to your Model (with a capital "M"). And if that means separating your data management (which usually translates to "persistence") from your business logic, then that's what it means. HTH, Dan From varun7rs at gmail.com Sun Jun 1 15:28:52 2014 From: varun7rs at gmail.com (varun7rs at gmail.com) Date: Sun, 1 Jun 2014 12:28:52 -0700 (PDT) Subject: Segmentation fault (core dumped) while using Cplex Python API Message-ID: Hello Everyone, I am trying to solve a mixed-integer problem using Cplex Python API and I get this error Segmentation fault (core dumped). i am not able to figure out the reason for this. Traceback srva at hades:~$ python RW10.py --output test --logPath log --xml topology.xml Start Time: 2014-6-1-20-56-39 CPLEX Parameter File Version 12.5.0.0 CPX_PARAM_TILIM 3600 CPX_PARAM_TRELIM 20000.00 CPX_PARAM_EPGAP 0.03 CPX_PARAM_EACHCUTLIM 2100000000 CPX_PARAM_FLOWCOVERS 0 CPX_PARAM_FLOWPATHS 0 CPX_PARAM_CLIQUES 0 CPX_PARAM_DISJCUTS 0 CPX_PARAM_COVERS 0 CPX_PARAM_ZEROHALFCUTS 0 CPX_PARAM_MIRCUTS 0 CPX_PARAM_MCFCUTS 0 CPX_PARAM_IMPLBD 0 CPX_PARAM_GUBCOVERS 0 CPX_PARAM_AGGCUTLIM 3 Completion Time: 972.63 Num Columns: 1350888 Num Rows: 25488 Solving Segmentation fault (core dumped) A few lines from the log file: Completion Time: 972.63 Num Columns: 1350888 Num Rows: 25488 Tried aggregator 1 time. MIP Presolve eliminated 12648 rows and 1321088 columns. MIP Presolve modified 180 coefficients. Reduced MIP has 12840 rows, 29800 columns, and 136000 nonzeros. Reduced MIP has 29800 binaries, 0 generals, 0 SOSs, and 0 indicators. Presolve time = 0.49 sec. (368.57 ticks) I would be grateful if someone can help me fix this. Thank You From gary.herron at islandtraining.com Sun Jun 1 15:44:58 2014 From: gary.herron at islandtraining.com (Gary Herron) Date: Sun, 01 Jun 2014 12:44:58 -0700 Subject: Segmentation fault (core dumped) while using Cplex Python API In-Reply-To: References: Message-ID: <538B82BA.1060301@islandtraining.com> On 06/01/2014 12:28 PM, varun7rs at gmail.com wrote: > Hello Everyone, > > I am trying to solve a mixed-integer problem using Cplex Python API and I get this error Segmentation fault (core dumped). i am not able to figure out the reason for this. > Traceback > > srva at hades:~$ python RW10.py --output test --logPath log --xml topology.xml > Start Time: 2014-6-1-20-56-39 > CPLEX Parameter File Version 12.5.0.0 > CPX_PARAM_TILIM 3600 > CPX_PARAM_TRELIM 20000.00 > CPX_PARAM_EPGAP 0.03 > CPX_PARAM_EACHCUTLIM 2100000000 > CPX_PARAM_FLOWCOVERS 0 > CPX_PARAM_FLOWPATHS 0 > CPX_PARAM_CLIQUES 0 > CPX_PARAM_DISJCUTS 0 > CPX_PARAM_COVERS 0 > CPX_PARAM_ZEROHALFCUTS 0 > CPX_PARAM_MIRCUTS 0 > CPX_PARAM_MCFCUTS 0 > CPX_PARAM_IMPLBD 0 > CPX_PARAM_GUBCOVERS 0 > CPX_PARAM_AGGCUTLIM 3 > > Completion Time: 972.63 > Num Columns: 1350888 > Num Rows: 25488 > Solving > Segmentation fault (core dumped) > > A few lines from the log file: > > Completion Time: 972.63 > Num Columns: 1350888 > Num Rows: 25488 > Tried aggregator 1 time. > MIP Presolve eliminated 12648 rows and 1321088 columns. > MIP Presolve modified 180 coefficients. > Reduced MIP has 12840 rows, 29800 columns, and 136000 nonzeros. > Reduced MIP has 29800 binaries, 0 generals, 0 SOSs, and 0 indicators. > Presolve time = 0.49 sec. (368.57 ticks) > > I would be grateful if someone can help me fix this. > > Thank You > > > You might be better off finding a CPLEX forum to ask this question. Nothing in this question looks like Python, (except I see you do run a Python script), the segmentation fault is most likely in CPLEX not in Python, and I've never seen CPLEX mention mentioned in this Python newsgroup. None of which means you won't get an answer here, but I think a CPLEX specific forum would be a better bet. Gary Herron From duncan.booth at invalid.invalid Sun Jun 1 16:43:06 2014 From: duncan.booth at invalid.invalid (Duncan Booth) Date: 1 Jun 2014 20:43:06 GMT Subject: Multi-line commands with 'python -c' References: Message-ID: Peter Otten <__peter__ at web.de> wrote: > Duncan Booth wrote: > >> Chris Angelico wrote: >> >>> On Sat, May 31, 2014 at 7:42 AM, Devin Jeanpierre >>> wrote: >>>> In unix shells you can literally use a new line. Or is that only >> bash? >>> >>> You can in bash, I know, but it's fiddly to type it; and more >>> importantly, it's not a good point in the "this is cleaner than a >>> series of pipes" argument. My primary recommendation, of course, was >>> a three-line script saved as an actual file, but for a more direct >>> parallel to the pipe-it-three-ways model, I wanted to use -c. >> >> and you also wrote originally that it's fiddly to edit. I think that >> Windows Powershell has (at least in the current ISE command line) got >> the editing a bit better. It's a minor difference though and it has >> taken Microsoft about 30 years to get to that point. >> >> What may be a larger difference, or may just be my lack of Linux-foo, >> is this: >> >> PS C:\python33> $script = @" >> import os >> for root, dirs, files in os.walk("."): >> if len(dirs + files) == 1: print(root) >> "@ >> >> PS C:\python33> python -c $script >> .\Doc >> .\Lib\concurrent\__pycache__ >> .\Lib\curses\__pycache__ >> ... >> >> which is a style I've found useful for example when running a group >> of related timeit.py commands as I can put things like multi-line >> setup statements in a variable and then have a simpler command to >> repeat. >> >> But bash as far as I can won't let me do that: >> >> $ script='import os >> for root, dirs, files in os.walk("."): >> if len(dirs + files) == 1: print(root) >> ' >> $ python -c $script >> File "", line 1 >> import >> ^ >> SyntaxError: invalid syntax > > $ script='import os >> for root, dirs, files in os.walk("."): >> if len(dirs + files) == 1: >> print(root) >> ' > $ python3 -c "$script" > . > ./heureka > > $ python3 -c 'import sys; print(sys.argv)' $script > ['-c', 'import', 'os', 'for', 'root,', 'dirs,', 'files', 'in', > 'os.walk("."):', 'if', 'len(dirs', '+', 'files)', '==', '1:', > 'print(root)'] $ python3 -c 'import sys; print(sys.argv)' "$script" > ['-c', 'import os\nfor root, dirs, files in os.walk("."):\n if > len(dirs + files) == 1:\n print(root)\n'] > Thanks, I thought there must be a way to do that (and I should have remembered it). It nicely shows up the difference between the *nix shells that are all about processing the command line as a string and the Powershell way where it is all about objects (so a single value stays as a single argument). -- Duncan Booth From 4kir4.1i at gmail.com Sun Jun 1 18:34:19 2014 From: 4kir4.1i at gmail.com (Akira Li) Date: Mon, 02 Jun 2014 02:34:19 +0400 Subject: Segmentation fault (core dumped) while using Cplex Python API References: Message-ID: <874n04qmxg.fsf@gmail.com> varun7rs at gmail.com writes: > Hello Everyone, > > I am trying to solve a mixed-integer problem using Cplex Python API > and I get this error Segmentation fault (core dumped). i am not able > to figure out the reason for this. > Traceback > > srva at hades:~$ python RW10.py --output test --logPath log --xml topology.xml > Start Time: 2014-6-1-20-56-39 > CPLEX Parameter File Version 12.5.0.0 > CPX_PARAM_TILIM 3600 > CPX_PARAM_TRELIM 20000.00 > CPX_PARAM_EPGAP 0.03 > CPX_PARAM_EACHCUTLIM 2100000000 > CPX_PARAM_FLOWCOVERS 0 > CPX_PARAM_FLOWPATHS 0 > CPX_PARAM_CLIQUES 0 > CPX_PARAM_DISJCUTS 0 > CPX_PARAM_COVERS 0 > CPX_PARAM_ZEROHALFCUTS 0 > CPX_PARAM_MIRCUTS 0 > CPX_PARAM_MCFCUTS 0 > CPX_PARAM_IMPLBD 0 > CPX_PARAM_GUBCOVERS 0 > CPX_PARAM_AGGCUTLIM 3 > > Completion Time: 972.63 > Num Columns: 1350888 > Num Rows: 25488 > Solving > Segmentation fault (core dumped) > > A few lines from the log file: > > Completion Time: 972.63 > Num Columns: 1350888 > Num Rows: 25488 > Tried aggregator 1 time. > MIP Presolve eliminated 12648 rows and 1321088 columns. > MIP Presolve modified 180 coefficients. > Reduced MIP has 12840 rows, 29800 columns, and 136000 nonzeros. > Reduced MIP has 29800 binaries, 0 generals, 0 SOSs, and 0 indicators. > Presolve time = 0.49 sec. (368.57 ticks) > > I would be grateful if someone can help me fix this. Install and enable faulthandler https://pypi.python.org/pypi/faulthandler/ to see where Segmentation fault happens -- akira From msardelich at gmail.com Sun Jun 1 18:43:22 2014 From: msardelich at gmail.com (Marcelo Sardelich) Date: Sun, 1 Jun 2014 15:43:22 -0700 (PDT) Subject: ImportError: No module named _gdb Message-ID: <431f3c0e-1cc3-43b2-91a0-34acf3b1da09@googlegroups.com> So I'm trying to implement pretty printing information using gdb-python27 on Windows7 Hopefully, someone experienced the same issue. GDB is working fine, but when I run gdb-python27 I got the following error (related to a python import): C:\MinGW\bin>gdb-python27.exe Traceback (most recent call last): File "", line 70, in File "", line 67, in GdbSetPythonDirectory File "c:\mingw\share\gdb/python\gdb\__init__.py", line 19, in import _gdb ImportError: No module named _gdb GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-mingw32". For bug reporting instructions, please see: . warning: File "C:\MinGW\bin\.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". (gdb) Does anybody have any clue about this issue? Best, Marcelo. PS: I posted same question to MinGW group, but maybe the issue is related to Python. Below, config information: OS Windows 7 C:\MinGW\bin>cat .gdbinit python import sys sys.path.insert(0, 'c:/gdb-printers/python') from libstdcxx.v6.printers import register_libstdcxx_printers register_libstdcxx_printers (None) end C:\MinGW\include>gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --ena ble-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv -prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T Thread model: win32 gcc version 4.8.1 (GCC) C:\MinGW\include>python Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> w32api.h (version): #define __W32API_VERSION 3.17 #define __W32API_MAJOR_VERSION 3 #define __W32API_MINOR_VERSION 17 _mingw.h (version): #define __MINGW_VERSION 4.0 #define __MINGW_MAJOR_VERSION 4 #define __MINGW_MINOR_VERSION 0 #define __MINGW_PATCHLEVEL 0 /* The following four macros are deprecated and will be removed * in the release greater than 4.1. */ #define __MINGW32_VERSION 3.20 #define __MINGW32_MAJOR_VERSION 3 #define __MINGW32_MINOR_VERSION 20 #define __MINGW32_PATCHLEVEL 0 From timothy.c.delaney at gmail.com Sun Jun 1 18:54:33 2014 From: timothy.c.delaney at gmail.com (Tim Delaney) Date: Mon, 2 Jun 2014 08:54:33 +1000 Subject: Python 3.2 has some deadly infection In-Reply-To: <538a8f48$0$29978$c3e8da3$5496439d@news.astraweb.com> References: <538a8f48$0$29978$c3e8da3$5496439d@news.astraweb.com> Message-ID: On 1 June 2014 12:26, Steven D'Aprano wrote: > > "with cross-platform behavior preferred over system-dependent one" -- > It's not clear how cross-platform behaviour has anything to do with the > Internet age. Python has preferred cross-platform behaviour forever, > except for those features and modules which are explicitly intended to be > interfaces to system-dependent features. (E.g. a lot of functions in the > os module are thin wrappers around OS features. Hence the name of the > module.) > There is the behaviour of defaulting input and output to the system encoding. I personally think we would all be better off if Python (and Java, and many other languages) defaulted to UTF-8. This hopefully would eventually have the effect of producers changing to output UTF-8 by default, and consumers learning to manually specify an encoding when it's not UTF-8 (due to invalid codepoints). I'm currently working on a product that interacts with lots of other products. These other products can be using any encoding - but most of the functions that interact with I/O assume the system default encoding of the machine that is collecting the data. The product has been in production for nearly a decade, so there's a lot of pushback against changes deep in the code for fear that it will break working systems. The fact that they are working largely by accident appears to escape them ... FWIW, changing to use iso-latin-1 by default would be the most sensible option (effectively treating everything as bytes), with the option for another encoding if/when more information is known (e.g. there's often a call to return the encoding, and the output of that call is guaranteed to be ASCII). Tim Delaney -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin at python.org Sun Jun 1 19:02:03 2014 From: benjamin at python.org (Benjamin Peterson) Date: Sun, 01 Jun 2014 16:02:03 -0700 Subject: [RELEASE] Python 2.7.7 Message-ID: <1401663723.32188.123962509.15B80988@webmail.messagingengine.com> I'm happy to announce the immediate availability of Python 2.7.7. Python 2.7.7 is a regularly scheduled bugfix release for the Python 2.7 series. This release includes months of accumulated bugfixes. All the changes in Python 2.7.7 are described in detail in the Misc/NEWS file of the source tarball. You can view it online at http://hg.python.org/cpython/raw-file/f89216059edf/Misc/NEWS The 2.7.7 release also contains fixes for two severe, if arcane, potential security vulnerabilities. The first was the possibility of reading arbitrary process memory using JSONDecoder.raw_decode. [1] (No other json APIs are affected.) The second security issue is an integer overflow in the strop module. [2] (You actually have no reason whatsoever to use the strop module.) Another security note for 2.7.7 is that the release includes a backport from Python 3 of hmac.compare_digest. This begins the implementation of PEP 466, Network Security Enhancements for Python 2.7.x. Downloads are at https://python.org/download/releases/2.7.7/ This is a production release. As always, please report bugs to http://bugs.python.org/ Build great things, Benjamin Peterson 2.7 Release Manager (on behalf of all of Python's contributors) [1] http://bugs.python.org/issue21529 [2] http://bugs.python.org/issue21530 From steve+comp.lang.python at pearwood.info Sun Jun 1 21:14:40 2014 From: steve+comp.lang.python at pearwood.info (Steven D'Aprano) Date: 02 Jun 2014 01:14:40 GMT Subject: Python 3.2 has some deadly infection References: <538a8f48$0$29978$c3e8da3$5496439d@news.astraweb.com> Message-ID: <538bcfff$0$29978$c3e8da3$5496439d@news.astraweb.com> On Mon, 02 Jun 2014 08:54:33 +1000, Tim Delaney wrote: > On 1 June 2014 12:26, Steven D'Aprano > wrote: > > >> "with cross-platform behavior preferred over system-dependent one" -- >> It's not clear how cross-platform behaviour has anything to do with the >> Internet age. Python has preferred cross-platform behaviour forever, >> except for those features and modules which are explicitly intended to >> be interfaces to system-dependent features. (E.g. a lot of functions in >> the os module are thin wrappers around OS features. Hence the name of >> the module.) >> >> > There is the behaviour of defaulting input and output to the system > encoding. That's a tricky one, but I think on balance that is a case where defaulting to the system encoding is the right thing to do. Input and out occurs on the local system you are running on, which by definition isn't cross-platform. (Non-local I/O is possible, but requires work -- it doesn't just happen.) > I personally think we would all be better off if Python (and > Java, and many other languages) defaulted to UTF-8. This hopefully would > eventually have the effect of producers changing to output UTF-8 by > default, and consumers learning to manually specify an encoding when > it's not UTF-8 (due to invalid codepoints). UTF-8 everywhere should be our ultimate aim. Then we can forget about legacy encodings except when digging out ancient documents from archived floppy disks :-) > I'm currently working on a product that interacts with lots of other > products. These other products can be using any encoding - but most of > the functions that interact with I/O assume the system default encoding > of the machine that is collecting the data. The product has been in > production for nearly a decade, so there's a lot of pushback against > changes deep in the code for fear that it will break working systems. > The fact that they are working largely by accident appears to escape > them ... > > FWIW, changing to use iso-latin-1 by default would be the most sensible > option (effectively treating everything as bytes), with the option for > another encoding if/when more information is known (e.g. there's often a > call to return the encoding, and the output of that call is guaranteed > to be ASCII). Python 2 does what you suggest, and it is *broken*. Python 2.7 creates moji-bake, while Python 3 gets it right: [steve at ando ~]$ python2.7 -c "print u'???'" ?????? [steve at ando ~]$ python3.3 -c "print(u'???')" ??? Latin-1 is one of those legacy encodings which needs to die, not to be entrenched as the default. My terminal uses UTF-8 by default (as it should), and if I use the terminal to input "???", Python ought to see what I input, not Latin-1 moji-bake. If I were to use Windows with a legacy code page, then I couldn't even enter "???" on the command line since none of the legacy encodings support that set of characters at the same time. I don't know exactly what I would get if I tried (say, by copying and pasting text from a Unicode-aware application), but I'd see that it was weird *in the shell* before it even reaches Python. On the other hand, if I were to input something supported by the legacy encoding, let's say I entered "???" while using ISO-8859-7 (Greek), then Python ought to see "???" and not moji-bake: py> b = "???".encode('iso-8859-7') # what the shell generates py> b.decode('latin-1') # what Python interprets those bytes as '???' Defaulting to the system encoding means that Python input and output just works, to the degree that input and output on your system just works. If your system is crippled by the use of a legacy encoding, then Python will at least be *no worse* than your system. -- Steven D'Aprano http://import-that.dreamwidth.org/ From timothy.c.delaney at gmail.com Sun Jun 1 22:23:05 2014 From: timothy.c.delaney at gmail.com (Tim Delaney) Date: Mon, 2 Jun 2014 12:23:05 +1000 Subject: Python 3.2 has some deadly infection In-Reply-To: <538bcfff$0$29978$c3e8da3$5496439d@news.astraweb.com> References: <538a8f48$0$29978$c3e8da3$5496439d@news.astraweb.com> <538bcfff$0$29978$c3e8da3$5496439d@news.astraweb.com> Message-ID: On 2 June 2014 11:14, Steven D'Aprano wrote: > On Mon, 02 Jun 2014 08:54:33 +1000, Tim Delaney wrote: > > I'm currently working on a product that interacts with lots of other > > products. These other products can be using any encoding - but most of > > the functions that interact with I/O assume the system default encoding > > of the machine that is collecting the data. The product has been in > > production for nearly a decade, so there's a lot of pushback against > > changes deep in the code for fear that it will break working systems. > > The fact that they are working largely by accident appears to escape > > them ... > > > > FWIW, changing to use iso-latin-1 by default would be the most sensible > > option (effectively treating everything as bytes), with the option for > > another encoding if/when more information is known (e.g. there's often a > > call to return the encoding, and the output of that call is guaranteed > > to be ASCII). > > Python 2 does what you suggest, and it is *broken*. Python 2.7 creates > moji-bake, while Python 3 gets it right: > The purpose of my example was to show a case where no thought was put into encodings - the assumption was that the system encoding and the remote system encoding would be the same. This is most definitely not the case a lot of the time. I also should have been more clear that *in the particular situation I was talking about* iso-latin-1 as default would be the right thing to do, not in the general case. Quite often we won't know the correct encoding until we've executed a command via ssh - iso-latin-1 will allow us to extract the info we need (which will generally be 7-bit ASCII) without the possibility of an invalid encoding. Sure we may get mojibake, but that's better than the alternative when we don't yet know the correct encoding. > Latin-1 is one of those legacy encodings which needs to die, not to be > entrenched as the default. My terminal uses UTF-8 by default (as it > should), and if I use the terminal to input "???", Python ought to see > what I input, not Latin-1 moji-bake. > For some purposes, there needs to be a way to treat an arbitrary stream of bytes as an arbitrary stream of 8-bit characters. iso-latin-1 is a convenient way to do that. It's not the only way, but settling on it and being consistent is better than not having a way. Tim Delaney -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody at gmail.com Sun Jun 1 22:46:52 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Sun, 1 Jun 2014 19:46:52 -0700 (PDT) Subject: Python 3.2 has some deadly infection In-Reply-To: References: <538a8f48$0$29978$c3e8da3$5496439d@news.astraweb.com> <538bcfff$0$29978$c3e8da3$5496439d@news.astraweb.com> Message-ID: <7bdd7967-deed-4bbc-b177-0a0202b2ab7f@googlegroups.com> On Monday, June 2, 2014 7:53:05 AM UTC+5:30, Tim Delaney wrote: > On 2 June 2014 11:14, Steven D'Aprano wrote: >> ?Latin-1 is one of those legacy encodings which needs to die, not to be >> entrenched as the default. My terminal uses UTF-8 by default (as it >> should), and if I use the terminal to input "???", Python ought to see >> what I input, not Latin-1 moji-bake. > For some purposes, there needs to be a way to treat an arbitrary > stream of bytes as an arbitrary stream of 8-bit > characters. iso-latin-1 is a convenient way to do that. It's not the > only way, but settling on it and being consistent is better than not > having a way. Here is a quote from the oracle docs: http://docs.oracle.com/cd/E23824_01/html/E26033/glmbx.html#glmar | The C locale, also known as the POSIX locale, is the POSIX system | default locale for all POSIX-compliant systems. In more layman language | ASCII also known as the 'Unix locale' is the default for all *nix | compliant systems which is a key aspect of what Ive called 'The UNIX Assumption' : http://blog.languager.org/2014/04/unicode-and-unix-assumption.html From sukesh.bheemineni at thomsonreuters.com Mon Jun 2 00:08:44 2014 From: sukesh.bheemineni at thomsonreuters.com (sukesh.bheemineni at thomsonreuters.com) Date: Mon, 2 Jun 2014 04:08:44 +0000 Subject: Connect to VectorWise database usin Python Message-ID: <310DE6674CE56549B4844B6CBE05B6EC68A7002A@BIAP-ERFMMBS28.ERF.thomson.com> Hi, Using python(2.7.2) I am not able to connect to Vector Wise database. Can you suggest me how I can connect to it. If you don't mind step by step :(. Regards, Sukesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From esj at harvee.org Mon Jun 2 00:16:55 2014 From: esj at harvee.org (Eric S. Johansson) Date: Mon, 02 Jun 2014 00:16:55 -0400 Subject: parsley parsing question Message-ID: <538BFAB7.6090602@harvee.org> how do you parse multi line text with parsley? here is a work in progress and I'm trying to figure out why I need to split the text and process per line vrs all at one go. thanks for any help. --- eric Here's the whole body of code --------------------------- import parsley # # grammar to parse # # uses # template