Re: IDE for python

[Marko Rauhamaa]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[Chris Angelico]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[Rustom Mody]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[Steven D'Aprano]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[Chris Angelico]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suds and Python3

[Burak Arslan]

Hello,

First, for such questions, there's always s...@python.org

On 31/05/14 21:59, Paul McNett wrote:
> On 5/31/14, 11:36 AM, tokib...@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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Steve Hayes]

On Sun, 1 Jun 2014 13:35:11 +1000, Chris Angelico  wrote:

>boeing-l...@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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Steve Hayes]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Mark Lawrence]

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


--
https://mail.python.org/mailman/listinfo/python-list

Drawing Sinus curve in Python

[Farzad Torabi]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Drawing Sinus curve in Python

[Steven D'Aprano]

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/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Command prompt not shown when running Python script with subprocess on Windows

[Tim Golden]

29/05/2014 20:21, ps16thypresenceisfullnessof...@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
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[alister]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Is MVC Design Pattern good enough?

[Ernest Bonat, Ph.D.]

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.bo...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[wxjmfauth]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[wxjmfauth]

Le mercredi 28 mai 2014 14:55:35 UTC+2, Chris Angelico a écrit :
> On Wed, May 28, 2014 at 9:46 PM, Greg Schroeder  wrote:
> 
> >> > Please suggest, if we have any free ide for python development.
> 
> >
> 
> > Anything that writes text is fine.
> 
> > I recommend the standard text editor for your OS (Notepad if you use
> 
> > Windows, Textedit on Mac, whatever is on your GNU/Linux distro by
> 
> > default) unless you know exactly what you don't like about it.
> 
> 
> 
> No. Don't use Notepad for anything! It's easy enough to get a better
> 
> editor. Among its other faults, Notepad:
> 
> 
> 
> 1) Has problems with LF line endings (they vanish, and you have hugely
> 
> long lines)
> 
> 2) Puts three junk bytes onto the beginning of a file that it
> 
> considers saved as UTF-8
> 
> 3) Doesn't understand coding cookies, and will happily save something
> 
> in a different encoding like CP-1252 (which it calls "ANSI")
> 
> 4) Guesses encodings on load, giving rise to the famous "Bush hid the
> 
> facts" trick - although this is unlikely to be a problem with
> 
> something of decent size
> 
> 5) Has issues with large files - or at least, it did last time I
> 
> tried; this may no longer be true with Windows 7/8
> 
> 
> 
> Default text editors on the Linux distros I've used have been far
> 
> better, but still less than ideal. With Debian Squeeze, I got a gedit
> 
> that bugged me in several ways, which is what pushed me onto SciTE.
> 
> You can certainly start coding with gedit, though. The issues that I
> 
> had with it were relating to heavy-duty usage that I do, where I'm
> 
> basically spending an entire day delving into code and moving stuff
> 
> around. These days, though, I'd rather have one editor on both the
> 
> platforms I use (Windows and Linux, each in multiple variants), as it
> 
> allows me to share configs and comfortable keystrokes. There are
> 
> plenty of cross-platform editors to choose from.
> 
> 
> 
> So, I agree with your analysis, as regards gedit ("know exactly what
> 
> you don't like about it"). If it doesn't bug you, use it. But if
> 
> Notepad doesn't bug you, *still don't use it*, because it's like
> 
> driving a car that isn't structurally sound. It might not be you that
> 
> gets hurt by it... or it might not be for quite a while that you see
> 
> the problems... but the pain will happen.
> 
> 
> 
> ChrisA



Amen.
Ite missa est.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[wxjmfauth]

Le vendredi 30 mai 2014 19:30:27 UTC+2, Rustom Mody a écrit :
> On Friday, May 30, 2014 10:47:33 PM UTC+5:30, wxjm...@gmail.com wrote:
> 
> > =
> 
> 
> 
> > Ok, thanks for the answer.
> 
> 
> 
> > "xetex does not quite work whereas pdflatex works smoothly"
> 
> 
> 
> > ?
> 
> 
> 
> Problem is a combination of
> 
> 1. I am a somewhat clueless noob
> 
> 2. xetex is emerging technology therefore changing fast and not stable
> 
> 
> 
> So when something does not work I dont know whether:
> 
> - its 1 (I am doing something silly)
> 
> - Or 2 (I have actually hit a bug)
> 
> 
> 
> I tried writing some small (hello-world) type text using unicode chars rather 
> 
> the old-fashioned \alpha type of locutions. It worked.
> 
> Added a bunch of more latex packages from apt.
> 
> It stopped working.
> 
> 
> 
> --
> 
> PS It would help all if you read
> 
> https://wiki.python.org/moin/GoogleGroupsPython
> 
> and dont double-space earlier mails.



It's not the place to discuss TeX here.
(I have actually 16 more or less complete "distros" on
my hd on Windows, all working very well. They are on
my hd, but all run from an usb stick as well!)

jmf
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Yet another "simple" headscratcher

[wxjmfauth]

>>> # from my lib
>>> def NewMat(nr, nc, val=0.0):
... val = float(val)
... return [[val] * nc for i in range(nr)]
... 
>>> import vmio6
>>> aa = NewMat(2, 3)
>>> vmio6.pr(aa)
(   0.0e+000  0.0e+000  0.0e+000 )
(   0.0e+000  0.0e+000  0.0e+000 )
>>> aa[0][0] = 3.1416
>>> vmio6.pr(aa)
(   3.14160e+000  0.0e+000  0.0e+000 )
(   0.0e+000  0.0e+000  0.0e+000 )
>>> aa[1][1] = 1.2345
>>> vmio6.pr(aa)
(   3.14160e+000  0.0e+000  0.0e+000 )
(   0.0e+000  1.23450e+000  0.0e+000 )
>>>

jmf
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[wxjmfauth]

Le vendredi 30 mai 2014 18:15:09 UTC+2, Rustom Mody a écrit :
> On Friday, May 30, 2014 8:36:54 PM UTC+5:30, wxjm...@gmail.com wrote:
> 
> 
> 
> > Out of curiosity.
> 
> > Are you the Rusi Mody attempting to dive in Xe(La)TeX?
> 
> 
> 
> Yeah :-)
> 
> 
> 
> As my blog posts labelled unicode will indicate I am a fan of using
> 
> unicode in program source:
> 
> http://blog.languager.org/search/label/Unicode
> 
> 
> 
> Of course it is not exactly a coincidence that I used APL a bit in my
> 
> early days.  At that time it was great fun though we did not take it
> 
> seriously.*
> 
> 
> 
> It is now about time that we stop taking ASCII seriously!!
> 
> 
> 
> And for those who dont know xetex, its is really xɘtex – a pictorial
> 
> anagram if written as XƎTEX
> 
> 
> 
> However in all fairness I should say that I cannot seem to find my
> 
> way to that promised land yet:
> 
> - xetex does not quite work whereas pdflatex works smoothly
> 
> - mathjax is awesome however its firmly latex (not xetex) based
> 
> 
> 
> ---
> 
> * And the fact that there are recent implementations including web ones means 
> its by no means dead:
> 
> http://baruchel.hd.free.fr/apps/apl/
> 

> which I think unicode aficionados will enjoy


=

Ok, thanks for the answer.


"xetex does not quite work whereas pdflatex works smoothly"

?

jmf



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[wxjmfauth]

Le samedi 31 mai 2014 14:30:11 UTC+2, Steven D'Aprano a écrit :
> On Sat, 31 May 2014 12:07:59 +0200, Steve Hayes wrote:
> 
> 
> 
> > I'll leave Python 3.2 on my computer, but 2.7.5 will be the one I'm
> 
> > installing now. Even if I could *find* a book that deals with Python
> 
> > 3.x, couldn't afford to but yet another Python book.
> 
> 
> 
> Version 2.7 is a good choice, and it will be around for a long time: it 
> 
> will be supported until at least 2020, so you should get many years of 
> 
> use from it.
> 
> 
> 
> Do not be discouraged about Python 3. There are differences, but they 
> 
> aren't so different as to be a major barrier. By the time you have a bit 
> 
> of experience with 2.7, you will be more than capable of dealing with the 
> 
> differences with version 3. They are not different languages, think of 
> 
> them as slightly different dialects of the same language, like UK and 
> 
> South African English.
> 
> 
> 
> 
==

At least Py2 does not crash when using non ascii
(eg sticking with cp1252).

I just noticed this last week, Thursday, when presenting
the absurdity of the Flexible String Representation.

jmf
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[wxjmfauth]

Le mercredi 28 mai 2014 22:24:15 UTC+2, Mark Lawrence a écrit :
> On 28/05/2014 20:58, Larry Martell wrote:
> 
> > On Wed, May 28, 2014 at 2:49 PM, Paul Rubin  
> > > wrote:
> 
> >
> 
> > Larry Martell  
> > > writes:
> 
> >  > Somthing I came across in my travels through the ether:
> 
> >  > [1]https://medium.com/@deliciousrobots/5d2ad703365d/
> 
> >
> 
> > "Python 3 can revive Python" https://medium.com/p/2a7af4788b10
> 
> >long HN comment thread: https://news.ycombinator.com/item?id=7801834
> 
> >
> 
> > "Python 3 is fine" http://sealedabstract.com/rants/python-3-is-fine/
> 
> >
> 
> > OT: wow that medium site is obnoxious.
> 
> >
> 
> >
> 
> > No company that I work for is using python 3 - they just have too much
> 
> > of an investment in a python 2 code base to switch. I'm just saying.
> 
> >
> 
> 
> 
> So you're happy because you've support until at least 2020, and the 
> 
> people using Python 3 are happy, mainly because of the vastly improved 
> 
> unicode handling via the FSR and asyncio in 3.4.  Presumably the only 
> 
> unhappy people are those who keep bleating on about forking Python to 
> 
> produce a 2.8, or has work on this already started without my knowledge?
> 
> 
> 
> -- 
> 
> My fellow Pythonistas, ask not what our language can do for you, ask 
> 
> what you can do for our language.
> 
> 
> 
> Mark Lawrence
> 
===

Unicode: a reason to not use Python.

jmf
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[wxjmfauth]

Le vendredi 30 mai 2014 16:04:18 UTC+2, Rustom Mody a écrit :
> On Friday, May 30, 2014 7:24:10 PM UTC+5:30, Marko Rauhamaa wrote:
> 
> > Rustom Mody wrote:
> 
> > 
> 
> > 
> 
> > >> > 3. Search unopened files (grep) for a string or re.
> 
> > >
> 
> > > How do you do this with emacs?
> 
> > > I find a menagerie of greppish commands -- rgrep, lgrep, grep-find etc
> 
> > 
> 
> > 
> 
> > 
> 
> > To grep for a pattern in the directory of the active buffer:
> 
> > 
> 
> > 
> 
> >M-x grep
> 
> >Run grep (like this): grep -nH -e 
> 
> 
> 
> Well...
> 
> lgrep is cleverer than grep (in a stupid sort of way :D )
> 
> Was just wondering if there were some other tricks



Out of curiosity.
Are you the Rusi Mody attempting to dive in Xe(La)TeX?

jmf
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDE for python

[wxjmfauth]

Le vendredi 30 mai 2014 18:38:04 UTC+2, Mark Lawrence a écrit :
> On 30/05/2014 17:15, Rustom Mody wrote:
> 
> > On Friday, May 30, 2014 8:36:54 PM UTC+5:30, wxjm...@gmail.com wrote:
> 
> >
> 
> > It is now about time that we stop taking ASCII seriously!!
> 
> >
> 
> 
> 
> This can't happen in the Python world until there is a sensible approach 
> 
> to unicode.  Ah, but wait a minute, the ball was set rolling with Python 
> 
> 3.0.  Then came PEP 393 and the Flexible String Representation in Python 
> 
> 3.3 and some strings came down in size by a factor of 75% and in most 
> 
> cases it was faster.  Just what do some people want in life, jam on it?
> 
> 
> 
> -- 
> 
> 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



A guy who is understanding unicode would not have even
spent its time in writing a PEP 393 proposal.

I skip the discussion(s) I read here and there about PDF.

Put this comment in relation with my Xe(La)TeX knowledge.

jmf
-- 
https://mail.python.org/mailman/listinfo/python-list

[OT] Re: Is MVC Design Pattern good enough?

[Dan Sommers]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Segmentation fault (core dumped) while using Cplex Python API

[varun7rs]

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@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 2.00
CPX_PARAM_EPGAP 0.03
CPX_PARAM_EACHCUTLIM 21
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



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Segmentation fault (core dumped) while using Cplex Python API

[Gary Herron]

On 06/01/2014 12:28 PM, varun...@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@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 2.00
CPX_PARAM_EPGAP 0.03
CPX_PARAM_EACHCUTLIM 21
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

--
https://mail.python.org/mailman/listinfo/python-list

Re: Multi-line commands with 'python -c'

[Duncan Booth]

Peter Otten <__pete...@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("."):\nif
> len(dirs + files) == 1:\nprint(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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Segmentation fault (core dumped) while using Cplex Python API

[Akira Li]

varun...@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@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 2.00
> CPX_PARAM_EPGAP 0.03
> CPX_PARAM_EACHCUTLIM 21
> 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

-- 
https://mail.python.org/mailman/listinfo/python-list

ImportError: No module named _gdb

[Marcelo Sardelich]

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_PATCHLEVEL0
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.2 has some deadly infection

[Tim Delaney]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASE] Python 2.7.7

[Benjamin Peterson]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.2 has some deadly infection

[Steven D'Aprano]

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@ando ~]$ python2.7 -c "print u'δжç'"
δжç
[steve@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/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.2 has some deadly infection

[Tim Delaney]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.2 has some deadly infection

[Rustom Mody]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Connect to VectorWise database usin Python

[sukesh.bheemineni]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

parsley parsing question

[Eric S. Johansson]

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
# returns(|file: |)
# remembers

# alt form
# template[:]

# test targets

def do_uses(a,b):
print "do_uses %s - %s -"% (a,b)
def do_returns(a):
print "do_returns %s"% (a)
def do_template(a):
print "do_templates %s"% (a)

# parsleyfied grammar
TF_grammar = r"""
kwToken = (letter|digit|'_')*
uses_statement = 'uses' ws kwToken:kwT ':' anything*:roL '\n'{0,1} -> 
do_uses ("".join(kwT), "".join(roL))
returns_statement = 'returns' ws kwToken:kwT '\n'{0,1} -> 
do_returns("".join(kwT))
template_statement = 'template' ws kwToken:kwT '\n'{0,1} -> 
do_template("".join(kwT))

bow = (uses_statement | returns_statement | template_statement) ws
"""
#
action_table = {
"do_uses": do_uses,
"do_returns": do_returns,
"do_template": do_template,
}

# alt path: split lines and parse them one at time

def run_bot(body_of_text):
"""break up the body of text"""
for i in body_of_text.split("\n"):
if len(i) != 0:  # why is this test needed?
x = parsley.makeGrammar(TF_grammar,action_table)
x(i).bow()

xxx="""uses foo: this is some text
returns xyzzy
template templatename
"""
# multi-line solution
x = parsley.makeGrammar(TF_grammar,action_table)
x(xxx).bow()

test line-at-a-time solution
run_bot(xxx)

--  bad result (multi-line) is ---

$ python parsleytest.py
do_uses foo -  this is some text
returns xyzzy
template templatename
 -

 good result should be ---

$ python parsleytest.py
do_uses foo  this is some text
do_returns xyzzy
do_template template templatename


--
https://mail.python.org/mailman/listinfo/python-list

Re: ImportError: No module named _gdb

[dieter]

Marcelo Sardelich  writes:
> 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

Likely, an external ("C") extension (named "_gdb") must be build
(and installed) - and apparently, this is not yet done in your installation.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Bob Martin]

in 722944 20140601 124133 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.

Concorde design started in the early 50s, 747 mid-to-late 60s.
-- 
https://mail.python.org/mailman/listinfo/python-list