date:20140106


On 01/05/2014 06:23 PM, Ethan Furman wrote:


Using my own project [1] as a reference


[1] https://pypi.python.org/pypi/dbf
--
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Tim Chase

On 2014-01-06 15:51, Chris Angelico wrote:
> >>> data = b"\x43\x6c\x67\x75\x62\x61" # is there an easier way to
> >>> turn a hex dump into a bytes literal?

Depends on how you source them:

# space separated:
>>> s1 = "43 6c 67 75 62 61"
>>> ''.join(chr(int(pair, 16)) for pair in s1.split())
'Clguba'

# all smooshed together:
>>> s2 = s1.replace(' ','')
>>> s2
'436c67756261'
>>> ''.join(chr(int(s2[i*2:(i+1)*2], 16)) for i in range(len(s2)/2))
'Clguba'

# as \xHH escaped:
>>> s3 = ''.join('\\x'+s2[i*2:(i+1)*2] for i in range(len(s2)/2))
>>> print(s3)
\x43\x6c\x67\x75\x62\x61
>>> print(b3)
b'\\x43\\x6c\\x67\\x75\\x62\\x61'
>>> b3.decode('unicode_escape')
'Clguba'

It might get more complex if you're not just dealing with bytes, or
if you have some other encoding scheme, but "s1" (space-separated, or
some other delimiter such as colon-separated that can be passed
to the .split() call) and "s2" (all smooshed together) are the two I
encounter most frequently.

-tkc

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

Re: "More About Unicode in Python 2 and 3"


On 1/5/14 11:26 PM, Terry Reedy wrote:

On 1/5/2014 8:16 PM, Ned Batchelder wrote:


OK, let's see what we got from three core developers on this list:


To me, the following is a partly unfair summary.


I apologize, I'm sure there were details I skipped in my short summary.




- Antoine dismissed the post as "a rant".


He called it a rant while acknowledging that there is a unsolved issue
with transforms. Whether he was 'dismissing' it or not, I do not know.
Antoine also noted that there does not seem to be anything new in this
post that Armin has not said before. Without reading in detail, I had
the same impression.


- Terry took issue with three claims made, and ended with, "I suspect
there are other basic errors, but I mostly quit reading at this point."


You are discouraged that I quit reading? How much sludge do you expect
me to wade through? If Armin wants my attention (and I do not think he
does), it is *his* responsibility to write in a readable manner.

But I read a bit more and found a 4th claim to 'take issue with' (to be
polite):
"only about 3% of all Python developers using Python 3 properly"
with a link to
http://alexgaynor.net/2014/jan/03/pypi-download-statistics/
The download statistics say nothing about the percent of all Python
developers using Python 3, let alone properly, and Alex Gaynor makes no
such claim as Armin did.

I would not be surprised if a majority of Python users have never
downloaded from pypi. What I do know from reading the catalog-sig (pypi)
list for a couple of years is that there are commercial developers who
use pypi heavily to update 1000s of installations and that they drive
the development of the pypi infrastructure. I strongly suspect that they
strongly skew the download statistics.

Dubious claim 5 is this: "For 97% of us, Python 2 is our beloved world
for years to come". For Armin's narrow circle, that may be true, but I
suspect that more than 3% of Python programmers have never written
Python2 only code.


- Serhiy made a sarcastic comment comparing Python 3's bytes/unicode
handling with Python 2's int/str handling, implying that since int/str
wasn't a problem, then bytes/unicode isn't either.


Serhiy's point was about the expectation of implicit conversion
(int/str) versus (bytes/str) and the complaint about removal of implicit
conversion. I suspect that part of his point is that if we never had
implicit bytes/unicode conversion, it would not be expected.



You are still talking about whether Armin is right, and whether he 
writes well, about flaws in his statistics, etc.  I'm talking about the 
fact that an organization (Python core development) has a product 
(Python 3) that is getting bad press.  Popular and vocal customers 
(Armin, Kenneth, and others) are unhappy.  What is being done to make 
them happy?  Who is working with them?  They are not unique, and their 
viewpoints are not outliers.


I'm not talking about the technical details of bytes and Unicode.  I'm 
talking about making customers happy.


--
Ned Batchelder, http://nedbatchelder.com

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

informal #python2.8 channel on freenode

2014-01-06 Thread Martijn Faassen


Fellow Pythoneers,

I've started an informal channel "#python2.8" on freenode. It's to 
discuss the potential for a Python 2.8 version -- to see whether there 
is interest in it, what it could contain, how it could facilitate 
porting to Python 3, who would work on it, etc. If you are interested in 
constructive discussion about a Python 2.8, please join.


I realize that if there is actual code created, and if it's not under 
the umbrella of the PSF, it couldn't be called "Python 2.8" due to 
trademark reasons. But that's premature - let's have some discussions 
first to see whether anything can happen.


Hope to see you there for some discussion!

Regards,

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

Re: function to split strings and lists on predicate

2014-01-06 Thread Dave Angel

On Mon, 06 Jan 2014 06:48:11 +, Mark Lawrence 
 wrote:
I came across this over the weekend 


http://paddy3118.blogspot.co.uk/2013/10/unifying-pythons-string-and-lis
t.html. 
  I couldn't come up with a solution to the fsplit function that 
seemed 
in any way cleaner.  What can our nest of avid Pythonistas come up 

with?

Looks like that link is already broken.  Try the first half of page:

http://paddy3118.blogspot.co.uk/2013_10_01_archive.html

I can't see any way to simplify the generator Paddy produced,  but 
the thing that bothered me is that it won't work on iterables, such 
as itself. For thar reason I think I'd stick with the separate 
functions,  or write an adaptor to convert a iterable of lists to one 
of strings.


--
DaveA

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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 12:39, Ned Batchelder wrote:


I'm not talking about the technical details of bytes and Unicode.  I'm
talking about making customers happy.



Simply scrap PEP 404 and the currently unhappy customers will be happy 
as they'll be free to do all the work they want on Python 2.8, as my 
understanding is that the vast majority of the Python core developers 
won't do it for them.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

word replacing in a paragraph

2014-01-06 Thread Frank Cui

Hey guys,
I'm trying to automate a process by initially creating a standard template and 
then replace some text fields with variable values.
[for example, "DATE" in the paragraph will be replaced by the current date 
value. it doesn't have to be a literal word of "DATE", "DATE" in "TESTDATE" can 
also be replaced.]
Is there some lightweight built-in or 3rd party  libraries which are good for 
such kind of work ?
ThanksFrank   -- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Gene Heskett

On Monday 06 January 2014 08:52:42 Ned Batchelder did opine:
[...]
> You are still talking about whether Armin is right, and whether he
> writes well, about flaws in his statistics, etc.  I'm talking about the
> fact that an organization (Python core development) has a product
> (Python 3) that is getting bad press.  Popular and vocal customers
> (Armin, Kenneth, and others) are unhappy.  What is being done to make
> them happy?  Who is working with them?  They are not unique, and their
> viewpoints are not outliers.
> 
> I'm not talking about the technical details of bytes and Unicode.  I'm
> talking about making customers happy.

+1 Ned. Quite well said.

And from my lurking here, its quite plain to me that 3.x python has a 
problem with everyday dealing with strings.  If it is not solved relatively 
quickly, then I expect there will be a fork, a 2.8 by those most heavily 
invested. Or an exodus to the next "cool" language.

No language will remain "cool" for long if it cannot simply and dependably 
solve the everyday problem of printing the monthly water bill.  If it can 
be done in assembly, C or even bash, then it should be doable in python 
even simpler.

Its nice to be able abstract the functions so they become one word macro's 
that wind up using 2 megs of program memory and 200k of stack to print 
Hello World, but I can do that with 3 or 4 lines of assembly on a coco3 
running nitros9.  Or 3 lines of C.  The assembly will use perhaps 20 bytes 
of stack, the C version maybe 30.  And the assembly will be lightening fast 
on a cpu with a less than 2 megahertz clock.

Given that the problem IS understood, a language that can simplify solving 
a problem is nice, and will be used.  But if the problem is not well 
understood, then you can write gigo crap in your choice of languages.

Python is supposed to be a problem solver, not a problem creator.

I'll get me coat. :)

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

We are using Linux daily to UP our productivity - so UP yours!
-- Adapted from Pat Paulsen by Joe Sloan
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: word replacing in a paragraph

2014-01-06 Thread David Froger

Quoting Frank Cui (2014-01-06 15:01:25)
> Hey guys,
> 
> I'm trying to automate a process by initially creating a standard template and
> then replace some text fields with variable values.
> 
> [for example, "DATE" in the paragraph will be replaced by the current date
> value. it doesn't have to be a literal word of "DATE", "DATE" in "TESTDATE" 
> can
> also be replaced.]
> 
> Is there some lightweight built-in or 3rd party  libraries which are good for
> such kind of work ?

Hi Franck,

There is the standard module:
http://docs.python.org/2/library/string.html#template-strings

Or maybe if you need more power, something like jinja2.  It's for Web (HTML
documents), but it can also be used for any kind of document.
http://jinja.pocoo.org/docs/

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

Re: word replacing in a paragraph

2014-01-06 Thread leo kirotawa

Since it is for a template you can round the keyword to be replaced ,
something like $data$ and then just  string.replace('$data','1234')




On Mon, Jan 6, 2014 at 12:01 PM, Frank Cui  wrote:

> Hey guys,
>
> I'm trying to automate a process by initially creating a standard template
> and then replace some text fields with variable values.
>
> [for example, "DATE" in the paragraph will be replaced by the current date
> value. it doesn't have to be a literal word of "DATE", "DATE" in "TESTDATE"
> can also be replaced.]
>
> Is there some lightweight built-in or 3rd party  libraries which are good
> for such kind of work ?
>
> Thanks
> Frank
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>


-- 
--
Leônidas S. Barbosa (Kirotawa)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 14:32, Gene Heskett wrote:

On Monday 06 January 2014 08:52:42 Ned Batchelder did opine:
[...]

You are still talking about whether Armin is right, and whether he
writes well, about flaws in his statistics, etc.  I'm talking about the
fact that an organization (Python core development) has a product
(Python 3) that is getting bad press.  Popular and vocal customers
(Armin, Kenneth, and others) are unhappy.  What is being done to make
them happy?  Who is working with them?  They are not unique, and their
viewpoints are not outliers.

I'm not talking about the technical details of bytes and Unicode.  I'm
talking about making customers happy.


+1 Ned. Quite well said.

And from my lurking here, its quite plain to me that 3.x python has a
problem with everyday dealing with strings.  If it is not solved relatively
quickly, then I expect there will be a fork, a 2.8 by those most heavily
invested. Or an exodus to the next "cool" language.



It's not at all plain to me, in fact quite the opposite.  Please expand 
on these problems for mere mortals such as myself.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: word replacing in a paragraph

On Tue, Jan 7, 2014 at 1:01 AM, Frank Cui  wrote:
> I'm trying to automate a process by initially creating a standard template
> and then replace some text fields with variable values.
>
> [for example, "DATE" in the paragraph will be replaced by the current date
> value. it doesn't have to be a literal word of "DATE", "DATE" in "TESTDATE"
> can also be replaced.]

How much do you trust the person creating that template? If it's you
yourself, then probably the easiest way is to use the inbuilt
str.format() method or %-formatting:

template = """Today is: %(date)s
Test ran on %(version)s, in %(time)f seconds."""

data = {"date":"2014-01-07", "version":"v3.4.0b2", "time":123.45}

print(template % data)

Today is: 2014-01-07
Test ran on v3.4.0b2, in 123.45 seconds.

This gives you a lot of flexibility, as you can lay things out tidily
as well as simply substituting in values.

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

Re: "More About Unicode in Python 2 and 3"


On 01/05/2014 06:37 PM, Dan Stromberg wrote:


The argument seems to be "3.x doesn't work the way I'm accustomed to,
so I'm not going to use it, and I'm going to shout about it until
others agree with me."


The argument is that a very important, if small, subset a data manipulation become very painful in Py3.  Not impossible, 
and not difficult, but painful because the mental model and the contortions needed to get things to work don't sync up 
anymore.  Painful because Python is, at heart, a simple and elegant language, but with the use-case of embedded ascii in 
binary data that elegance went right out the window.


On 01/05/2014 06:55 PM, Chris Angelico wrote:


It can't be both things. It's either bytes or it's text.


Of course it can be:

000: 0372 0106   6100 1d00    .r..a...
010:          
020: 4e41 4d45    0043 0100   NAME...C
030: 1900         
040: 4147 4500    004e 1a00   AGEN
050: 0300         
060: 0d1a 0a  ...

And there we are, mixed bytes and ascii data.  As I said earlier, my example is minimal, but still very frustrating in 
that normal operations no longer work.  Incidentally, if you were thinking that NAME and AGE were part of the ascii 
text, you'd be wrong -- the field names are also encoded, as are the Character and Memo fields.


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

Re: "More About Unicode in Python 2 and 3"

On Tue, Jan 7, 2014 at 2:10 AM, Ethan Furman  wrote:
> On 01/05/2014 06:55 PM, Chris Angelico wrote:
>>
>>
>> It can't be both things. It's either bytes or it's text.
>
>
> Of course it can be:
>
> 000: 0372 0106   6100 1d00    .r..a...
> 010:          
> 020: 4e41 4d45    0043 0100   NAME...C
> 030: 1900         
> 040: 4147 4500    004e 1a00   AGEN
> 050: 0300         
> 060: 0d1a 0a  ...
>
> And there we are, mixed bytes and ascii data.  As I said earlier, my example
> is minimal, but still very frustrating in that normal operations no longer
> work.  Incidentally, if you were thinking that NAME and AGE were part of the
> ascii text, you'd be wrong -- the field names are also encoded, as are the
> Character and Memo fields.

That's alternating between encoded text and non-text bytes. Each
individual piece is either text or non-text, not both. The ideal way
to manipulate it would most likely be a simple decode operation that
turns this into (probably) a dictionary, decoding both the
structure/layout and UTF-8 in a single operation. But a less ideal
(and more convenient) solution might be involving what's currently
under discussion elsewhere: a (possibly partial) percent-formatting or
.format() method for bytes.

None of this changes the fact that there are bytes used to
store/transmit stuff, and abstract concepts used to manipulate them.
Just like nobody expects to be able to write a dict to a file without
some form of encoding (pickle, JSON, whatever), you shouldn't expect
to write a character string without first turning it into bytes.

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

Re: [OT] Migrating from non-free programs to LibreOffice (was: "More About Unicode in Python 2 and 3")

2014-01-06 Thread Grant Edwards

On 2014-01-06, Chris Angelico  wrote:

>> Right. I think shifting people to LibreOffice is an excellent and
>> realistic step toward imcreasing people's software and data freedom.
>
> Yeah. Which is why I do it. But the other night, my mum was trying to
> lay out her book in LO, and was having some problems with the system
> of having each chapter in a separate file. (Among other things, styles
> weren't shared across them all, so a tweak to a style means opening up
> every chapter and either doing a parallel edit or figuring out how to
> import styles.) So yes, it's a realistic and worthwhile step, but it's
> not a magic solution to all problems. She doesn't have time to learn a
> whole new system. Maybe - in the long term - LaTeX would actually save
> her time, but it's certainly a much harder 'sell' than LO.

Yea, I think laying out a book with something like MS Word or
LibreOffice is nuts.   Depending on her formatting needs, a
lighter-weight mark-up language (something like asciidoc) might suite:

  http://asciidoc.org/
  http://en.wikipedia.org/wiki/AsciiDoc

I've used it to write a 150 page manual, and was quite happy with the
results.  It produces DocBook XML, PDF, HTML and a few other output
formats (Including, I think, LibreOffice/OpenOffice).  It's _much_
easier to get started with than LaTeX. For printing purposes the
quality of the output is no match for TeX -- but it's better than a
"word processor", and it does a very nice job with HTML output.

-- 
Grant Edwards   grant.b.edwardsYow! It's a hole all the
  at   way to downtown Burbank!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: word replacing in a paragraph

2014-01-06 Thread Jean-Michel Pichavant


- Original Message - 

> Hey guys,

> I'm trying to automate a process by initially creating a standard
> template and then replace some text fields with variable values.

> [for example, "DATE" in the paragraph will be replaced by the current
> date value. it doesn't have to be a literal word of "DATE", "DATE"
> in "TESTDATE" can also be replaced.]

> Is there some lightweight built-in or 3rd party libraries which are
> good for such kind of work ?

> Thanks
> Frank

Jinja2 would be able to do it, with very few line of code.
And you get all the features provided by a template engine should you need them 
to build more advanced templates.

JM


-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be 
privileged. If you are not the intended recipient, please notify the sender 
immediately and do not disclose the contents to any other person, use it for 
any purpose, or store or copy the information in any medium. Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [ANN] gg_scrapper -- scrapping of the Google Groups

2014-01-06 Thread Grant Edwards

On 2014-01-05, Ethan Furman  wrote:
> Mat??j,
>
> Thanks for your efforts!
>
> However, you should only have one 'p' in scraping and scraper.  ;)

Rats.  I thought he had figured out a way to scrap GG.

-- 
Grant Edwards   grant.b.edwardsYow! Like I always say
  at   -- nothing can beat
  gmail.comthe BRATWURST here in
   DUSSELDORF!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

Roy Smith wrote:

> In article ,
>  Chris Angelico  wrote:
> 
>> It can't be both things. It's either bytes or it's text.
> 
> I've never used Python 3, so forgive me if these are naive questions.
> Let's say you had an input stream which contained the following hex
> values:
> 
> $ hexdump data
> 000 d7 a8 a3 88 96 95
> 
> That's EBCDIC for "Python".  What would I write in Python 3 to read that
> file and print it back out as utf-8 encoded Unicode?

There's no one EBCDIC encoding. Like the so-called "extended ASCII"
or "ANSI" encodings that followed, IBM had many different versions of
EBCDIC customised for different machines and markets -- only even more
poorly documented. But since the characters in that are all US English
letters, any EBCDIC dialect ought to do it:

py> b = b'\xd7\xa8\xa3\x88\x96\x95'
py> b.decode('CP500')
'Python'

To read it from a file:

text = open("somefile", encoding='CP500').read()

And to print out the UTF-8 encoded bytes:

print(text.encode('utf-8'))

> Or, how about a slightly different example:
> 
> $ hexdump data
> 000 43 6c 67 75 62 61
> 
> That's "Python" in rot-13 encoded ascii.  How would I turn that into
> cleartext Unicode in Python 3?

In Python 3.3, you can do this:

py> b = b'\x43\x6c\x67\x75\x62\x61'
py> s = b.decode('ascii')
py> print(s)
Clguba
py> import codecs
py> codecs.decode(s, 'rot-13')
'Python'

(This may not work in Python 3.1 or 3.2, since rot13 and assorted other
string-to-string and byte-to-byte codecs were mistakenly removed. I say
mistakenly, not in the sense of "by accident", but in the sense of "it was
an error of judgement". Somebody was under the misapprehension that the
codec machinery could only work on Unicode <-> bytes.)

If you don't want to use the codec, you can do it by hand:

def rot13(astring):
result = []
for c in astring:
i = ord(c)
if ord('a') <= i <= ord('m') or ord('A') <= i <= ord('M'):
i += 13
elif ord('n') <= i <= ord('z') or ord('N') <= i <= ord('Z'):
i -= 13
result.append(chr(i))
return ''.join(result)

But why would you want to do it the slow way?

-- 
Steven

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

Re: "More About Unicode in Python 2 and 3"

Ned Batchelder  nedbatchelder.com> writes:
> 
> You can look through his problems and decide that he's "wrong," or that 
> he's "ranting," but that doesn't change the fact that Python 3 is 
> encountering friction.  What happens when a significant fraction of your 
> customers are "wrong"?

Well, yes, there is some friction and this is quite expectable, when
shipping incompatible changes. Other pieces of software have undergone a
similar process (e.g. Apache 1.x -> Apache 2.x).

(the alternative is to maintain a piece of software that sticks with obsolete
conventions, e.g. emacs)

> Core developers: I thank you for the countless hours you have devoted to 
> building all of the versions of Python.  I'm sure in many ways it's a 
> thankless task.  But you have a problem.  What's the point in being 
> right if you end up with a product that people don't use?

People don't use? According to available figures, there are more downloads of
Python 3 than downloads of Python 2 (Windows installers, mostly):
http://www.python.org/webstats/

The number of Python 3-compatible packages has been showing a constant and
healthy increase for years:
http://dev.pocoo.org/~gbrandl/py3.html

And Dan's survey shows 77% of respondents think Python 3 wasn't a mistake:
https://wiki.python.org/moin/2.x-vs-3.x-survey

> Maybe there are core developers who are trying hard to solve the 
> problems Kenneth and Armin are facing.  It would be great if that work 
> was more visible.  I don't see it, and apparently Armin doesn't either.

While this is being discussed:
https://mail.python.org/pipermail/python-dev/2014-January/130923.html

I would still point out that "Kenneth and Armin" are not the whole Python
community. Your whole argument seems to be that a couple "revered" (!!)
individuals should see their complaints taken for granted. I am opposed to 
rockstarizing the community.

Their contribution is always welcome, of course.

(as for network programming, the people working on and with asyncio don't
seem to find Python 3 terrible)

Regards

Antoine.

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

Re: "More About Unicode in Python 2 and 3"

On Tue, Jan 7, 2014 at 3:24 AM, Steven D'Aprano
 wrote:
> If you don't want to use the codec, you can do it by hand:
>
> def rot13(astring):
> result = []
> for c in astring:
> i = ord(c)
> if ord('a') <= i <= ord('m') or ord('A') <= i <= ord('M'):
> i += 13
> elif ord('n') <= i <= ord('z') or ord('N') <= i <= ord('Z'):
> i -= 13
> result.append(chr(i))
> return ''.join(result)
>
> But why would you want to do it the slow way?

Eww. I'd much rather use .translate() than that :)

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

Re: [OT] Migrating from non-free programs to LibreOffice (was: "More About Unicode in Python 2 and 3")

On Tue, Jan 7, 2014 at 2:53 AM, Grant Edwards  wrote:
> Yea, I think laying out a book with something like MS Word or
> LibreOffice is nuts.   Depending on her formatting needs, a
> lighter-weight mark-up language (something like asciidoc) might suite:
>
>   http://asciidoc.org/
>   http://en.wikipedia.org/wiki/AsciiDoc
>
> I've used it to write a 150 page manual, and was quite happy with the
> results.  It produces DocBook XML, PDF, HTML and a few other output
> formats (Including, I think, LibreOffice/OpenOffice).  It's _much_
> easier to get started with than LaTeX. For printing purposes the
> quality of the output is no match for TeX -- but it's better than a
> "word processor", and it does a very nice job with HTML output.

Hmm. Might be useful in some other places. I'm currently trying to
push for a web site design that involves docutils/reStructuredText,
but am flexible on the exact markup system used. My main goal, though,
is to separate content from structure and style - and my secondary
goal is to have everything done as plain text files (apart from actual
images), so the source control diffs are useful :)

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

Re: "More About Unicode in Python 2 and 3"

On Tue, Jan 7, 2014 at 3:29 AM, Antoine Pitrou  wrote:
> People don't use? According to available figures, there are more downloads of
> Python 3 than downloads of Python 2 (Windows installers, mostly):
> http://www.python.org/webstats/
>

Unfortunately, that has a massive inherent bias, because there are
Python builds available in most Linux distributions - and stats from
those (like Debian's popcon) will be nearly as useless, because a lot
of them will install one or the other (probably 2.x) without waiting
for the user (so either they'll skew in favour of the one installed,
or in favour of the one NOT installed, because that's the only one
that'll be explicitly requested). It's probably fairly accurate for
Windows stats, though, since most people who want Python on Windows
are going to come to python.org for an installer.

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

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Gene Heskett

On Monday 06 January 2014 11:42:55 Mark Lawrence did opine:

> On 06/01/2014 14:32, Gene Heskett wrote:
> > On Monday 06 January 2014 08:52:42 Ned Batchelder did opine:
> > [...]
> > 
> >> You are still talking about whether Armin is right, and whether he
> >> writes well, about flaws in his statistics, etc.  I'm talking about
> >> the fact that an organization (Python core development) has a
> >> product (Python 3) that is getting bad press.  Popular and vocal
> >> customers (Armin, Kenneth, and others) are unhappy.  What is being
> >> done to make them happy?  Who is working with them?  They are not
> >> unique, and their viewpoints are not outliers.
> >> 
> >> I'm not talking about the technical details of bytes and Unicode. 
> >> I'm talking about making customers happy.
> > 
> > +1 Ned. Quite well said.
> > 
> > And from my lurking here, its quite plain to me that 3.x python has a
> > problem with everyday dealing with strings.  If it is not solved
> > relatively quickly, then I expect there will be a fork, a 2.8 by
> > those most heavily invested. Or an exodus to the next "cool"
> > language.
> 
> It's not at all plain to me, in fact quite the opposite.  Please expand
> on these problems for mere mortals such as myself.

Mortals?  Likely nobody here is more acutely aware of his mortality Mark.

But what is the most common post here asking for help?  Tossup as to 
whether its database related, or strings.  Most everything else seems to be 
a pretty distant 3rd.

Cheers, Gene
 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

Ethan Furman wrote:

> Using my own project [1] as a reference:  good ol' dbf files -- character
> fields, numeric fields, logic fields, time fields, and of course the
> metadata that describes these fields and the dbf as a whole.  The
> character fields I turn into unicode, no sweat.  The metadata fields are
> simple ascii, and in Py2 something like `if header[FIELD_TYPE] == 'C'` did
> the job just fine.  In Py3 that compares an int (67) to the unicode letter
> 'C' and returns False.  

Why haven't you converted the headers to text too? You're using them as if
they were text. They might happen to merely contain the small subset of
Unicode which matches the ASCII encoding, but that in itself is no good
reason to keep it as bytes. If you want to work with stuff as if it were
text, convert it to text.

If you do have a good reason for keeping them as bytes, say because you need
to do a bunch of bitwise operations on it, it's not that hard to do the job
correctly: instead of defining FIELD_TYPE as 3 (for example), define it as
slice(3,4). Then:

if header[FIELD_TYPE] == b'C':

will work. For sure, this is a bit of a nuisance, and slightly error-prone,
since Python won't complain if you forget the b prefix, it will silently
return False. Which is the right thing to do, inconvenient though it may be
in this case. But it is workable, with a bit of discipline.

Or define a helper, and use that:

def eq(byte, char):
return byte == ord(char)

if eq(header[FIELD_TYPE], 'C'):

Worried about the cost of all those function calls, all those ord()'s? I'll
give you the benefit of the doubt and assume that this is not premature
optimisation. So do it yourself:

C = ord('C')  # Convert it once.
if header[FIELD_TYPE] == C:  # And use it many times.

[Note to self: when I'm BDFL, encourage much more compile-time
optimisations.]

> For me this is simply a major annoyance, but I 
> only have a handful of places where I have to deal with this.  Dealing
> with protocols where bytes is the norm and embedded ascii is prevalent --
> well, I can easily imagine the nightmare.

Is it one of those nightmares where you're being chased down an endless long
corridor by a small kitten wanting hugs? 'Cos so far I'm not seeing the
terror...

-- 
Steven

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

Re: "More About Unicode in Python 2 and 3"


On 01/06/2014 07:46 AM, Chris Angelico wrote:


None of this changes the fact that there are bytes used to
store/transmit stuff, and abstract concepts used to manipulate them.
Just like nobody expects to be able to write a dict to a file without
some form of encoding (pickle, JSON, whatever), you shouldn't expect
to write a character string without first turning it into bytes.


Writing is only half the battle, and not, as it happens, where I experience the pain.  This data must also be /read/. 
It has been stated many times that the Py2 str became the Py3 bytes, and yet never in Py2 did 'abc'[1] return 98.


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

Re: "More About Unicode in Python 2 and 3"

On Tue, Jan 7, 2014 at 3:43 AM, Steven D'Aprano
 wrote:
>> For me this is simply a major annoyance, but I
>> only have a handful of places where I have to deal with this.  Dealing
>> with protocols where bytes is the norm and embedded ascii is prevalent --
>> well, I can easily imagine the nightmare.
>
> Is it one of those nightmares where you're being chased down an endless long
> corridor by a small kitten wanting hugs? 'Cos so far I'm not seeing the
> terror...

Uhh, I think you're the only one here who has that nightmare, like
Chris Knight with his sun-god robes and naked women throwing pickles
at him.

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

Re: python finance

2014-01-06 Thread d ss

what the heck!
who told you this is a spam!
this is a call for cooperation and collaboration
how retarded!

On Sunday, January 5, 2014 4:14:22 AM UTC-5, [email protected] wrote:
> On Thursday, January 2, 2014 11:37:59 AM UTC, d ss wrote:
> 
> > dailystockselect.com needs a couple of talented python people for the 
> > development and implementation of new trading strategies. it may be also 
> > some pythonic design change for the displayed figures  now the web app 
> > consists of 1 of the 8 conceived strategies. contact us at the email on the 
> > website for more details 
> 
> > Samir
> 
> 
> 
> Please this is a spam.. I've reported this as a spam. I wish everyone who 
> sees this also reports it as spam to get the user bannned. This way GG will 
> be a wee bit better
> 
> 
> 
> Thanks

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

Re: python finance

On Tue, Jan 7, 2014 at 3:58 AM, d ss  wrote:
> what the heck!
> who told you this is a spam!
> this is a call for cooperation and collaboration
> how retarded!

It is, at best, misdirected. There is a Python job board [1] where
these sorts of things can be posted, but the main mailing list isn't
the place for it.

However, if you want your posts to be seen as legitimate, I would
recommend putting a little more content into them, and putting some
effort into the quality of English. Most of us will just skip over
something that looks like unsolicited commercial email, if we even see
it at all (spam filtering is getting pretty effective these days).

ChrisA

[1] http://www.python.org/community/jobs/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Migrating from non-free programs to LibreOffice


On 01/06/2014 07:53 AM, Grant Edwards wrote:


Yea, I think laying out a book with something like MS Word or
LibreOffice is nuts.   Depending on her formatting needs, a
lighter-weight mark-up language (something like asciidoc) might suite:

   http://asciidoc.org/
   http://en.wikipedia.org/wiki/AsciiDoc


Thanks for that!

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

Which python framework?

2014-01-06 Thread blissend

I love programming in python but I'm having trouble deciding over a framework 
for a single player MUD like game I'm making for fun. Ideally it's a 
cross-platform free framework in case I want make it open source later with 
good capabilities of customizing the GUI look/style.

Currently I'm using wxpython which is great but I'm reading that if I want more 
customization over the look (i.e. a frame being all black and not using windows 
7 blue borders) then I may want to look elsewhere? If so what would be more 
ideal?

Keep in mind this is only a text based game so 3D is not needed. Perhaps I have 
to forgo my love of python for something else? Something comparable to 
appealing look of python syntax?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which python framework?

On Tue, Jan 7, 2014 at 4:02 AM,   wrote:
> I love programming in python but I'm having trouble deciding over a framework 
> for a single player MUD like game I'm making for fun. Ideally it's a 
> cross-platform free framework in case I want make it open source later with 
> good capabilities of customizing the GUI look/style.

If by "MUD-like" you mean that it's fundamentally based on scrolling
text and inputted commands, you may be able to just skip the GUI
altogether and use the console (print() and input()). That'd save you
a lot of trouble. Alternatively, it might be worth going the other way
and actually making it a MUD. Wait for a socket connection, let the
user TELNET in. Your GUI would then be an actual MUD client, off the
shelf, giving you all its features absolutely for free. Either way,
you put zero effort into building a GUI, and you get something every
bit as powerful as you could build manually.

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

Re: python finance

2014-01-06 Thread Grant Edwards

On 2014-01-06, Chris Angelico  wrote:
> On Tue, Jan 7, 2014 at 3:58 AM, d ss  wrote:
>> what the heck!
>> who told you this is a spam!
>> this is a call for cooperation and collaboration
>> how retarded!
>
> It is, at best, misdirected. There is a Python job board [1] where
> these sorts of things can be posted, but the main mailing list isn't
> the place for it.
>
> However, if you want your posts to be seen as legitimate, I would
> recommend [...]

And don't post them via Google Groups.  Chris's reply is the first
post in this thread that many of us saw.  ;)

-- 
Grant Edwards   grant.b.edwardsYow! Used staples are good
  at   with SOY SAUCE!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 16:46, Gene Heskett wrote:

On Monday 06 January 2014 11:42:55 Mark Lawrence did opine:


On 06/01/2014 14:32, Gene Heskett wrote:

On Monday 06 January 2014 08:52:42 Ned Batchelder did opine:
[...]


You are still talking about whether Armin is right, and whether he
writes well, about flaws in his statistics, etc.  I'm talking about
the fact that an organization (Python core development) has a
product (Python 3) that is getting bad press.  Popular and vocal
customers (Armin, Kenneth, and others) are unhappy.  What is being
done to make them happy?  Who is working with them?  They are not
unique, and their viewpoints are not outliers.

I'm not talking about the technical details of bytes and Unicode.
I'm talking about making customers happy.


+1 Ned. Quite well said.

And from my lurking here, its quite plain to me that 3.x python has a
problem with everyday dealing with strings.  If it is not solved
relatively quickly, then I expect there will be a fork, a 2.8 by
those most heavily invested. Or an exodus to the next "cool"
language.


It's not at all plain to me, in fact quite the opposite.  Please expand
on these problems for mere mortals such as myself.


Mortals?  Likely nobody here is more acutely aware of his mortality Mark.

But what is the most common post here asking for help?  Tossup as to
whether its database related, or strings.  Most everything else seems to be
a pretty distant 3rd.

Cheers, Gene




As the take of Python 3 is so poor then that must mean all the problems 
being reported are still with Python 2.  The solution is to upgrade to 
Python 3.3+ and the superb PEP 393 FSR which is faster and uses less 
memory.  Or is it simply that people are so used to doing things 
sloppily with Python 2 that they don't like being forced into doing 
things correctly with Python 3?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

class inheritance python2.7 vs python3.3

2014-01-06 Thread jwe . van . dijk

I have problems with these two classes:

class LPU1():
def __init__(self, formula):
"""
formula is a string that is parsed into a SymPy function
and several derived functions
"""
self.formula = formula
... ...

class LPU3(LPU1):
def __new__(self):
"""
the same functions as LPU1 but some added functions
and some functions redefined
"""
... ...

if __name__ == '__main__:
y = y = 'x_0 * x_1 + x_2'
stats1 = LPU1(y)
stats3 = LPU3(y)

Worked perfectly on Python 2.7.5+ but on Python 3.3.2+ I get on 
instantiatiating stat3:
TypeError: __new__() takes 1 positional argument but 2 were given

What am I doing wrong?
I must confess I am a bit out of my depth here so any explanation will be a 
learning experience.

Many thanks, Janwillem
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance python2.7 vs python3.3

On Tue, Jan 7, 2014 at 4:14 AM,   wrote:
> class LPU3(LPU1):
> def __new__(self):
> """
> the same functions as LPU1 but some added functions
> and some functions redefined
> """

You probably don't want to be using __new__ here. Try using __init__
instead, or simply not defining __new__ at all.

I suspect that the reason that appears to work under Py2 is that
you're using an old-style class, there. That means it'll be subtly
different on the two versions. To make them do the same thing,
explicitly subclass object:

class LPU1(object):

In Python 3, that's redundant - subclassing object is the default. In
Python 2, though, it's important.

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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 16:43, Steven D'Aprano wrote:

Ethan Furman wrote:


For me this is simply a major annoyance, but I
only have a handful of places where I have to deal with this.  Dealing
with protocols where bytes is the norm and embedded ascii is prevalent --
well, I can easily imagine the nightmare.


Is it one of those nightmares where you're being chased down an endless long
corridor by a small kitten wanting hugs? 'Cos so far I'm not seeing the
terror...



Great minds think alike? :)

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"

Ethan Furman wrote:

> On 01/05/2014 06:37 PM, Dan Stromberg wrote:
>>
>> The argument seems to be "3.x doesn't work the way I'm accustomed to,
>> so I'm not going to use it, and I'm going to shout about it until
>> others agree with me."
> 
> The argument is that a very important, if small, subset a data
> manipulation become very painful in Py3.  Not impossible, and not
> difficult, but painful because the mental model and the contortions needed
> to get things to work don't sync up
> anymore.  Painful because Python is, at heart, a simple and elegant
> language, but with the use-case of embedded ascii in binary data that
> elegance went right out the window.
> 
> On 01/05/2014 06:55 PM, Chris Angelico wrote:
>>
>> It can't be both things. It's either bytes or it's text.
> 
> Of course it can be:
> 
> 000: 0372 0106   6100 1d00    .r..a...
> 010:          
> 020: 4e41 4d45    0043 0100   NAME...C
> 030: 1900         
> 040: 4147 4500    004e 1a00   AGEN
> 050: 0300         
> 060: 0d1a 0a  ...
> 
> And there we are, mixed bytes and ascii data.  

Chris didn't say "bytes and ascii data", he said "bytes and TEXT".
Text != "ascii data", and the fact that some people apparently think it
does is pretty much the heart of the problem.

I see no mixed bytes and text. I see bytes. Since the above comes from a
file, it cannot be anything else but bytes. Do you think that a file that
happens to be a JPEG contains pixels? No. It contains bytes which, after
decoding, represents pixels. Same with text, ascii or otherwise.

Now, it is true that some of those bytes happen to fall into the same range
of values as ASCII-encoded text. They may even represent text after
decoding, but since we don't know what the file contents mean, we can't
know that. It might be a mere coincidence that the four bytes starting at
hex offset 40 is the C long 1095189760 which happens to look like "AGE"
with a null at the end. For historical reasons, your hexdump utility
performs that decoding step for you, which is why you can see "NAME"
and "AGE" in the right-hand block, but that doesn't mean the file contains
text. It contains bytes, some of which represents text after decoding.

If you (generic you) don't get that, you'll have a bad time. I mean *really*
get it, deep down in the bone. The long, bad habit of thinking as
ASCII-encoded bytes as text is the problem here. The average programmer has
years and years of experience thinking about decoding bytes to numbers and
back (just not by that name), so it doesn't lead to any cognitive
dissonance to think of hex 4147 4500 as either four bytes, two double-byte
ints, or a single four-byte int. But as soon as "text" comes into the
picture, the average programmer has equally many years of thinking that the
byte 41 "just is" the letter "A", and that's simply *wrong*.

> As I said earlier, my 
> example is minimal, but still very frustrating in
> that normal operations no longer work.  Incidentally, if you were thinking
> that NAME and AGE were part of the ascii text, you'd be wrong -- the field
> names are also encoded, as are the Character and Memo fields.

What Character and Memo fields? Are you trying to say that the NAME and AGE
are *not* actually ASCII text, but a mere coincidence, like my example of
1095189760? Or are you referring to the fact that they're actually encoded
as ASCII? If not, I have no idea what you are trying to say.

-- 
Steven

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

Re: "More About Unicode in Python 2 and 3"

Gene Heskett wrote:

> And from my lurking here, its quite plain to me that 3.x python has a
> problem with everyday dealing with strings.

I've been using Python 3.x since Python 3.1 came out, and I haven't come
across any meaningful problems with the everyday dealing with strings.
Quite the opposite -- I never quite understood the difference between text
strings and byte strings until I started using Python 3.

Perhaps you would care to explain what these everyday problems are that you
have seen?

-- 
Steven

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

Re: Which python framework?

2014-01-06 Thread blissend

On Monday, January 6, 2014 12:09:28 PM UTC-5, Chris Angelico wrote:
> On Tue, Jan 7, 2014 at 4:02 AM,   wrote:
> 
> > I love programming in python but I'm having trouble deciding over a 
> > framework for a single player MUD like game I'm making for fun. Ideally 
> > it's a cross-platform free framework in case I want make it open source 
> > later with good capabilities of customizing the GUI look/style.
> 
> 
> 
> If by "MUD-like" you mean that it's fundamentally based on scrolling
> 
> text and inputted commands, you may be able to just skip the GUI
> 
> altogether and use the console (print() and input()). That'd save you
> 
> a lot of trouble. Alternatively, it might be worth going the other way
> 
> and actually making it a MUD. Wait for a socket connection, let the
> 
> user TELNET in. Your GUI would then be an actual MUD client, off the
> 
> shelf, giving you all its features absolutely for free. Either way,
> 
> you put zero effort into building a GUI, and you get something every
> 
> bit as powerful as you could build manually.
> 
> 
> 
> ChrisA

I suppose what I'm trying to accomplish isn't ordinary. Yes, it's fundamentally 
a scrolling text based game but... with input commands only as a secondary 
option. I'm going to design a new user experience I have in mind via a GUI that 
can engage users without having to type commands. This is why I'm wondering 
about alternatives.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance python2.7 vs python3.3

2014-01-06 Thread Dave Angel


On Mon, 6 Jan 2014 09:14:08 -0800 (PST), [email protected] wrote:

I have problems with these two classes:




class LPU1() :


You forgot to derive from object. That's implied on 3.x, but you say 
you're also running on 2.7  Without naming your base class you're 
asking for an old style class which has been obsolete maybe 10 years. 
I sure don't recall how it differs.



def __init__(self, formula):
"""
formula is a string that is parsed into a SymPy function
and several derived functions
"""
self.formula = formula
... ...




class LPU3(LPU1):
def __new__(self):
"""
the same functions as LPU1 but some added functions
and some functions redefined


You don't show where you call super, so we can't tell what you had in 
mind. And did you actually mean __new__ here or should you have 
defined __init__ as you did in the base class?



if __name__ == '__main__:
y = y = 'x_0 * x_1 + x_2'
stats1 = LPU1(y)
stats3 = LPU3(y)


And where did you expect that y to go?


Worked perfectly on Python 2.7.5+ but on Python 3.3.2+ I get on 

instantiatiating stat3:

I don't see anything called stat3. Presumably you mean stats3, but 
you're not instantiating it you're instantiating LPU3.



TypeError: __new__() takes 1 positional argument but 2 were given


You forgot to include the rest of the stack trace.


I think the real problem is you forgot to include the second 
parameter on the misnamed __init__ method. It should have parameters 
self and arg, and pass arg up through super.


--
DaveA

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

Re: "More About Unicode in Python 2 and 3"

Ned Batchelder wrote:

> You are still talking about whether Armin is right, and whether he
> writes well, about flaws in his statistics, etc.  I'm talking about the
> fact that an organization (Python core development) has a product
> (Python 3) that is getting bad press.  Popular and vocal customers
> (Armin, Kenneth, and others) are unhappy.  What is being done to make
> them happy?  Who is working with them?  They are not unique, and their
> viewpoints are not outliers.
> 
> I'm not talking about the technical details of bytes and Unicode.  I'm
> talking about making customers happy.

Oh? How much did Armin pay for his Python support? If he didn't pay, he's
not a customer. He's a user.

When something gets bad press, the normal process is to first determine just
how justified that bad press is. (Unless, of course, you're more interested
in just *covering it up* than fixing the problem.) The best solutions are:

- if the bad press is justified, admit it, and fix the problems;

- if the bad press is not justified, try to educate Armin (and others) so
they stop blaming Python for their own errors; try to counter their bad
press with good press; or ignore it, knowing that the internet is
notoriously fickle and in a week people will be hating on Go, or Ruby
instead.

But I get the idea from your post that you don't want to talk about the
technical details of bytes and Unicode, and by extension, whether Python 3
is better or worse than Python 2. That makes it impossible to determine how
valid the bad press is, which leaves us hamstrung. Our only responses are:

- Patronise him. "Yes yes, you poor little thing, we feel your pain. But
what can we do about it?"

- Abuse him and hope he shuts up.

- Give in to his (and by extension, everyone elses) complaints, whether
justified or not, and make Python worse.

- Counter his bad press with good press, and come across as arrogant idiots
by denying actual real problems (if any).

- Wait for the Internet to move on.

-- 
Steven

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

Re: class inheritance python2.7 vs python3.3

[email protected] wrote:

> I have problems with these two classes:
> 
> class LPU1():
> def __init__(self, formula):
> """
> formula is a string that is parsed into a SymPy function
> and several derived functions
> """
> self.formula = formula
> ... ...
> 
> class LPU3(LPU1):
> def __new__(self):
> """
> the same functions as LPU1 but some added functions
> and some functions redefined
> """
> ... ...

If this actually is your class, then in Python 2.7 the __new__ method will
do nothing at all.

However, if you actually inherited from object in LPU1, then it (might) work
in Python 2.7. In Python 3.3, it will work regardless. Perhaps you have a
bug in the __new__ method? In Python 2.7, it is never called, and so the
bug never occurs. In Python 3.3, it is called, and the bug occurs.

> Worked perfectly on Python 2.7.5+ but on Python 3.3.2+ I get on
> instantiatiating stat3: TypeError: __new__() takes 1 positional argument
> but 2 were given

And sure enough, that's exactly it.

> What am I doing wrong?
> I must confess I am a bit out of my depth here so any explanation will be
> a learning experience.

Back in the Dark Ages of Python 1.x, built-in types like int, str, list and
so forth were completely independent of classes created with the class
statement. So you couldn't subclass them.

In Python 2.2, Python underwent what was called "class/type unification",
which added a new mechanism to allow built-in types to be subclassed. For
reasons of backward compatibility, the existing classes were left alone,
and were called "old style" or "classic" classes. But a new built-in,
called object, was created. All the other built-in types (str, list, int,
etc.) inherit from object. These became known as "new style classes".

New style classes had extra features that classic classes don't have,
including the __new__ constructor method. (Classic classes don't let you
override the constructor, only the initializer, __init__. New-style classes
let you override both.)

So Python 2.2 and beyond has two distinct models for classes, which *mostly*
work the same but have a few differences -- those that inherit from object
or some other built-in type, and those that don't.

# Python 2 classic class:
class LPU1():
 def __new__(cls): ...

__new__ is dead code here, and won't be called.

# Python 2 new-style class:
class LPU1(object):
 def __new__(cls): ...

__new__ is called.

So when you inherit from LPU1, your LPU3 class gets the same "old"
versus "new" behaviour, and __new__ is either dead code or not.

Now fast forward to Python 3. In Python 3, having two types of classes was
considered one too many. The old-style classes were dropped. Inheriting
from object became optional. Either way, you would get the same behaviour,
and __new__ is always used. So if you have a buggy __new__ method, it could
be ignored in Python 2 and suddenly run in Python 3, giving you an error.

-- 
Steven

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

Re: informal #python2.8 channel on freenode

2014-01-06 Thread Emile van Sebille

Why not contribute to the planned Stackless 2.8?  As I understand their 
direction, they'll be backporting certain v3.x features and will be 
prepping both SLP and nonSLP versions.


Emile


On 01/06/2014 04:45 AM, Martijn Faassen wrote:

Fellow Pythoneers,

I've started an informal channel "#python2.8" on freenode. It's to
discuss the potential for a Python 2.8 version -- to see whether there
is interest in it, what it could contain, how it could facilitate
porting to Python 3, who would work on it, etc. If you are interested in
constructive discussion about a Python 2.8, please join.

I realize that if there is actual code created, and if it's not under
the umbrella of the PSF, it couldn't be called "Python 2.8" due to
trademark reasons. But that's premature - let's have some discussions
first to see whether anything can happen.

Hope to see you there for some discussion!

Regards,

Martijn



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

/usr/lib/python2.7/subprocess.py:OSError: [Errno 2] No such file or directory

2014-01-06 Thread Marco Ippolito

Hi everybody,
I'm trying to use MEGAM with NLTK.

running the file:

 [Found /home/ubuntu/nltk_data/megam_i686.opt:
 /home/ubuntu/nltk_data/megam_i686.opt]
 Traceback (most recent call last):
   File "classifying.py", line 494, in 
 me_classifier = MaxentClassifier.train(train_feats, algorithm='megam')
   File "/usr/local/lib/python2.7/dist-packages/nltk/classify/maxent.py",
 line 319, in train
 gaussian_prior_sigma, **cutoffs)
   File "/usr/local/lib/python2.7/dist-packages/nltk/classify/maxent.py",
 line 1522, in train_maxent_classifier_with_megam
 stdout = call_megam(options)
   File "/usr/local/lib/python2.7/dist-packages/nltk/classify/megam.py",
 line 167, in call_megam
 p = subprocess.Popen(cmd, stdout=subprocess.PIPE)
   File "/usr/lib/python2.7/subprocess.py", line 679, ininit
 errread, errwrite)
   File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
 raise child_exception
 OSError: [Errno 2] No such file or directory

subprocess.py exists:

# subprocess - Subprocesses with accessible I/O streams
#
# For more information about this module, see PEP 324.
#
# This module should remain compatible with Python 2.2, see PEP 291.
#
# Copyright (c) 2003-2005 by Peter Astrand 
#
# Licensed to PSF under a Contributor Agreement.
# See http://www.python.org/2.4/license for licensing details.

r"""subprocess - Subprocesses with accessible I/O streams

 Any hints or suggestions?

 Thank you very much for your help.

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

Re: "More About Unicode in Python 2 and 3"

On 01/06/2014 09:27 AM, Steven D'Aprano wrote:

Ethan Furman wrote:

Chris didn't say "bytes and ascii data", he said "bytes and TEXT".
Text != "ascii data", and the fact that some people apparently think it
does is pretty much the heart of the problem.

The heart of a different problem, not this one. The problem I refer to is that many binary formats have well-defined
ascii-encoded text tidbits. These tidbits were quite easy to work with in Py2, not difficult but not elegant in Py3,
and even worse if you have to support both 2 and 3.

Now, it is true that some of those bytes happen to fall into the same range
of values as ASCII-encoded text. They may even represent text after
decoding, but since we don't know what the file contents mean, we can't
know that.

Of course we can -- we're the programmer, after all. This is not a random bunch of bytes but a well defined format for
storing data.

It might be a mere coincidence that the four bytes starting at
hex offset 40 is the C long 1095189760 which happens to look like "AGE"
with a null at the end. For historical reasons, your hexdump utility
performs that decoding step for you, which is why you can see "NAME"
and "AGE" in the right-hand block, but that doesn't mean the file contains
text. It contains bytes, some of which represents text after decoding.

As it happens, 'NAME' and 'AGE' are encoded, and will be decoded. They could just as easily have contained tilde's,
accents, umlauts, and other strange (to me) characters. It's actually the 'C' and the 'N' that bug me (like I said, my
example is minimal, especially compared to a network protocol).

And you're right -- it is easy to say FIELD_TYPE = slice(15,16), and it was also easy to say FIELD_TYPE = 15, but there
is a critical difference -- can you spot it?

..
..
..
In case you didn't: both work in Py2, only the slice version works (correctly) in Py3, but the worst part is why do I
have to use a slice to take a single byte when a simple index should work? Because the bytes type lies. It shows, for
example, b'\r\n\x12\x08N\x00' but when I try to access that N to see if this is a Numeric field I get:

--> b'\r\n\x12\x08N\x00'[4]
78

This is a cognitive dissonance that one does not expect in Python.

If you (generic you) don't get that, you'll have a bad time. I mean *really*
get it, deep down in the bone. The long, bad habit of thinking as
ASCII-encoded bytes as text is the problem here.

Different problem. The problem here is that bytes and byte literals don't
compare equal.

the average programmer has equally many years of thinking that the
byte 41 "just is" the letter "A", and that's simply *wrong*.

Agreed. But byte 41 != b'A', and that is equally wrong.

As I said earlier, my
example is minimal, but still very frustrating in
that normal operations no longer work. Incidentally, if you were thinking
that NAME and AGE were part of the ascii text, you'd be wrong -- the field
names are also encoded, as are the Character and Memo fields.

What Character and Memo fields? Are you trying to say that the NAME and AGE
are *not* actually ASCII text, but a mere coincidence, like my example of
1095189760? Or are you referring to the fact that they're actually encoded
as ASCII? If not, I have no idea what you are trying to say.

Yes, NAME and AGE are *not* ASCII text, but latin-1 encoded. The C and the N are ASCII, meaningful as-is. The actual
data stored in a Character (NAME in this case) or Memo (not shown) field would also be latin-1 encoded. (And before you
ask, the encoding is stored in the file header.)

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

Re: Which python framework?

2014-01-06 Thread blissend

On Monday, January 6, 2014 12:37:24 PM UTC-5, [email protected] wrote:
> On Monday, January 6, 2014 12:09:28 PM UTC-5, Chris Angelico wrote:
> 
> > On Tue, Jan 7, 2014 at 4:02 AM,   wrote:
> 
> > 
> 
> > > I love programming in python but I'm having trouble deciding over a 
> > > framework for a single player MUD like game I'm making for fun. Ideally 
> > > it's a cross-platform free framework in case I want make it open source 
> > > later with good capabilities of customizing the GUI look/style.
> 
> > 
> 
> > 
> 
> > 
> 
> > If by "MUD-like" you mean that it's fundamentally based on scrolling
> 
> > 
> 
> > text and inputted commands, you may be able to just skip the GUI
> 
> > 
> 
> > altogether and use the console (print() and input()). That'd save you
> 
> > 
> 
> > a lot of trouble. Alternatively, it might be worth going the other way
> 
> > 
> 
> > and actually making it a MUD. Wait for a socket connection, let the
> 
> > 
> 
> > user TELNET in. Your GUI would then be an actual MUD client, off the
> 
> > 
> 
> > shelf, giving you all its features absolutely for free. Either way,
> 
> > 
> 
> > you put zero effort into building a GUI, and you get something every
> 
> > 
> 
> > bit as powerful as you could build manually.
> 
> > 
> 
> > 
> 
> > 
> 
> > ChrisA
> 
> 
> 
> I suppose what I'm trying to accomplish isn't ordinary. Yes, it's 
> fundamentally a scrolling text based game but... with input commands only as 
> a secondary option. I'm going to design a new user experience I have in mind 
> via a GUI that can engage users without having to type commands. This is why 
> I'm wondering about alternatives.

It appears pyqt has better theming capabilities from what I'm reading up on.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which python framework?


On 06/01/2014 19:07, [email protected] wrote:

Would you please read and action this 
https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing 
double line spacing, thanks.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"

> The argument is that a very important, if small, subset a data manipulation
> become very painful in Py3.  Not impossible, and not difficult, but painful
> because the mental model and the contortions needed to get things to work
> don't sync up anymore.

You are confused.  Please see my reply to you on the bytestring type thread.

> Painful because Python is, at heart, a simple and
> elegant language, but with the use-case of embedded ascii in binary data
> that elegance went right out the window.

It went out the window only because the Object model with the
type/class unification was wrong.  It was fine before.

Mark

>> It can't be both things. It's either bytes or it's text.
>
> Of course it can be:
>
> 000: 0372 0106   6100 1d00    .r..a...
> 010:          
> 020: 4e41 4d45    0043 0100   NAME...C
> 030: 1900         
> 040: 4147 4500    004e 1a00   AGEN
> 050: 0300         
> 060: 0d1a 0a  ...
>
> And there we are, mixed bytes and ascii data.

No, you are printing a debug output which shows both.  That's called CHEATING.

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

the Gravity of Python 2


http://blog.startifact.com/posts/python-2-gravity.html

"A Way Forward - How to go forward then? I think it makes sense to work 
as hard as possible to lift those Python 2 codebases out of the gravity 
well."


I think this is complete nonsense.  There's only been five years since 
the first release of Python 3.  Surely much more time should be made 
available for people using Python 2 to plan for a migration?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"

>> Chris didn't say "bytes and ascii data", he said "bytes and TEXT".
>> Text != "ascii data", and the fact that some people apparently think it
>> does is pretty much the heart of the problem.
>
> The heart of a different problem, not this one.  The problem I refer to is
> that many binary formats have well-defined ascii-encoded text tidbits.

Really?  If people are using binary with "well-defined ascii-encoded
tidbits", they're doing something wrong.  Perhaps you think escape
characters "\n" are "well defined tidbits", but YOU WOULD BE WRONG.
The purpose of binary is to keep things raw.  WTF?  You guys are so
strange.

>
>> If you (generic you) don't get that, you'll have a bad time. I mean
>> *really*
>> get it, deep down in the bone. The long, bad habit of thinking as
>> ASCII-encoded bytes as text is the problem here.

I think the whole forking community is confused at because of your own
arrogance.  Foo(l)s.

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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 19:30, Mark Janssen wrote:

Chris didn't say "bytes and ascii data", he said "bytes and TEXT".
Text != "ascii data", and the fact that some people apparently think it
does is pretty much the heart of the problem.


The heart of a different problem, not this one.  The problem I refer to is
that many binary formats have well-defined ascii-encoded text tidbits.


Really?  If people are using binary with "well-defined ascii-encoded
tidbits", they're doing something wrong.  Perhaps you think escape
characters "\n" are "well defined tidbits", but YOU WOULD BE WRONG.
The purpose of binary is to keep things raw.  WTF?  You guys are so
strange.




If you (generic you) don't get that, you'll have a bad time. I mean
*really*
get it, deep down in the bone. The long, bad habit of thinking as
ASCII-encoded bytes as text is the problem here.


I think the whole forking community is confused at because of your own
arrogance.  Foo(l)s.

markj



Looks like another bad batch, time to change your dealer again.

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: the Gravity of Python 2

> http://blog.startifact.com/posts/python-2-gravity.html
>
> "A Way Forward - How to go forward then? I think it makes sense to work as
> hard as possible to lift those Python 2 codebases out of the gravity well."
>
> I think this is complete nonsense.  There's only been five years since the
> first release of Python 3.  Surely much more time should be made available
> for people using Python 2 to plan for a migration?

What makes no sense is that you've started a whole 'nother thread on
an issue whose gravity is right here, already on the list.  Add your
new commentary and links to existing threads would be easier, yes?

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

Re: "More About Unicode in Python 2 and 3"

> Looks like another bad batch, time to change your dealer again.

??? Strange, when the debate hits bottom, accusations about doing
drugs come up.  This is like the third reference (and I don't even
drink alcohol).

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

Re: the Gravity of Python 2


On 06/01/2014 19:41, Mark Janssen wrote:

http://blog.startifact.com/posts/python-2-gravity.html

"A Way Forward - How to go forward then? I think it makes sense to work as
hard as possible to lift those Python 2 codebases out of the gravity well."

I think this is complete nonsense.  There's only been five years since the
first release of Python 3.  Surely much more time should be made available
for people using Python 2 to plan for a migration?


What makes no sense is that you've started a whole 'nother thread on
an issue whose gravity is right here, already on the list.  Add your
new commentary and links to existing threads would be easier, yes?



I've just had a really good chuckle reading that coming from you.  Got 
the new dealer yet?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

[email protected]

2014-01-06 Thread 7390621



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Drawing shaded area depending on distance with latitude and altitude coordinate

2014-01-06 Thread Isaac Won

I have tried to make a plot of points with longitude and latitude coordinate, 
and draw shaded area with distance from one point. So, I thought that I could 
uae contourf function from matplotlibrary. My code is:
import haversine
import numpy as np
import matplotlib.pyplot as plt
with open(filin, 'r') as f:
arrays = [map(float, line.split()) for line in f]
newa = [[x[1],-x[2]] for x in arrays]

lat = np.zeros(275)
lon = np.zeros(275)
for c in range(0,275):
lat[c] = newa[c][0]
lon[c] = newa[c][1]

with open(filin, 'r') as f:
arrays = [map(float, line.split()) for line in f]
newa = [[x[1],-x[2]] for x in arrays]

lat = np.zeros(275)
lon = np.zeros(275)
for c in range(0,275):
lat[c] = newa[c][0]
lon[c] = newa[c][1]


dis = np.zeros(275)

for c in range(0,275):
dis[c] = haversine.distance(newa[0],[lat[c],lon[c]])

dis1 = [[]]*1

for c in range(0,275):
dis1[0].append(dis[c])


cs = plt.contourf(lon,lat,dis1)
cb = plt.colorbar(cs)

plt.plot(-lon[0],lat[0],'ro')
plt.plot(-lon[275],lat[275],'ko')
plt.plot(-lon[1:275],lat[1:275],'bo')
plt.xlabel('Longitude(West)')
plt.ylabel('Latitude(North)')
plt.gca().invert_xaxis()
plt.show()

My idea in this code was that I could made a shaded contour by distance from a 
certain point which was noted as newa[0] in the code. I calculated distances 
between newa[0] and other points by haversine module which calculate distances 
with longitudes and latitudes of two points. However, whenever I ran this code, 
I got the error related to X, Y or Z in contourf such as:
TypeError: Length of x must be number of columns in z, and length of y must 
be number of rows.

IF I use meshgrid for X and Y, I also get:
TypeError: Inputs x and y must be 1D or 2D.

I just need to draw shaded contour with distance from one point on the top of 
the plot of each point.

If you give any idea or hint, I will really apprecite. Thank you, Isaac
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"


On 1/6/2014 9:32 AM, Gene Heskett wrote:


And from my lurking here, its quite plain to me that 3.x python has a
problem with everyday dealing with strings.


Strings of what? And what specific 'everyday' problem are you referring to?

--
Terry Jan Reedy

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

Re: Drawing shaded area depending on distance with latitude and altitude coordinate


On 06/01/2014 20:08, Isaac Won wrote:

I have tried to make a plot of points with longitude and latitude coordinate, 
and draw shaded area with distance from one point. So, I thought that I could 
uae contourf function from matplotlibrary. My code is:
 import haversine
 import numpy as np
 import matplotlib.pyplot as plt
 with open(filin, 'r') as f:
 arrays = [map(float, line.split()) for line in f]
 newa = [[x[1],-x[2]] for x in arrays]

 lat = np.zeros(275)
 lon = np.zeros(275)
 for c in range(0,275):
 lat[c] = newa[c][0]
 lon[c] = newa[c][1]

 with open(filin, 'r') as f:
 arrays = [map(float, line.split()) for line in f]
 newa = [[x[1],-x[2]] for x in arrays]

 lat = np.zeros(275)
 lon = np.zeros(275)
 for c in range(0,275):
 lat[c] = newa[c][0]
 lon[c] = newa[c][1]


 dis = np.zeros(275)

 for c in range(0,275):
 dis[c] = haversine.distance(newa[0],[lat[c],lon[c]])

 dis1 = [[]]*1

 for c in range(0,275):
 dis1[0].append(dis[c])


 cs = plt.contourf(lon,lat,dis1)
 cb = plt.colorbar(cs)

 plt.plot(-lon[0],lat[0],'ro')
 plt.plot(-lon[275],lat[275],'ko')
 plt.plot(-lon[1:275],lat[1:275],'bo')
 plt.xlabel('Longitude(West)')
 plt.ylabel('Latitude(North)')
 plt.gca().invert_xaxis()
 plt.show()

My idea in this code was that I could made a shaded contour by distance from a 
certain point which was noted as newa[0] in the code. I calculated distances 
between newa[0] and other points by haversine module which calculate distances 
with longitudes and latitudes of two points. However, whenever I ran this code, 
I got the error related to X, Y or Z in contourf such as:
 TypeError: Length of x must be number of columns in z, and length of y 
must be number of rows.

IF I use meshgrid for X and Y, I also get:
 TypeError: Inputs x and y must be 1D or 2D.

I just need to draw shaded contour with distance from one point on the top of 
the plot of each point.

If you give any idea or hint, I will really apprecite. Thank you, Isaac



Sorry I can't help directly but can point you here 
https://lists.sourceforge.net/lists/listinfo/matplotlib-users or perhaps 
stackoverflow.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Serhiy Storchaka


06.01.14 06:51, Chris Angelico написав(ла):

data = b"\x43\x6c\x67\x75\x62\x61" # is there an easier way to turn a hex dump 
into a bytes literal?


>>> bytes.fromhex('43 6c 67 75 62 61')
b'Clguba'


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

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Serhiy Storchaka


06.01.14 06:41, Tim Chase написав(ла):

from codecs import getencoder
getencoder("rot-13")(s2.decode('utf-8'))[0]

'Python'


codecs.decode('rot13', s2.decode())


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

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Serhiy Storchaka


06.01.14 15:44, Mark Lawrence написав(ла):

Simply scrap PEP 404 and the currently unhappy customers will be happy
as they'll be free to do all the work they want on Python 2.8, as my
understanding is that the vast majority of the Python core developers
won't do it for them.


It's not necessary. You are free to make a fork and call it Qython 2.8.

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

Re: "More About Unicode in Python 2 and 3"

Chris Angelico  gmail.com> writes:
> 
> On Tue, Jan 7, 2014 at 3:29 AM, Antoine Pitrou  pitrou.net>
wrote:
> > People don't use? According to available figures, there are more
downloads of
> > Python 3 than downloads of Python 2 (Windows installers, mostly):
> > http://www.python.org/webstats/
> >
> 
> Unfortunately, that has a massive inherent bias, because there are
> Python builds available in most Linux distributions - and stats from
> those (like Debian's popcon) will be nearly as useless, because a lot
> of them will install one or the other (probably 2.x) without waiting
> for the user (so either they'll skew in favour of the one installed,
> or in favour of the one NOT installed, because that's the only one
> that'll be explicitly requested). It's probably fairly accurate for
> Windows stats, though, since most people who want Python on Windows
> are going to come to python.org for an installer.

Agreed, but it's enough to rebut the claim that "people don't use
Python 3". More than one million Python 3.3 downloads per month under
Windows is a very respectable number (no 2.x release seems to reach
that level).

Regards

Antoine.


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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 20:31, Serhiy Storchaka wrote:

06.01.14 15:44, Mark Lawrence написав(ла):

Simply scrap PEP 404 and the currently unhappy customers will be happy
as they'll be free to do all the work they want on Python 2.8, as my
understanding is that the vast majority of the Python core developers
won't do it for them.


It's not necessary. You are free to make a fork and call it Qython 2.8.



You plural is fine, you singular simply doesn't apply, it'll stop 
raining in the UK first :)


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Tim Chase

On 2014-01-06 22:20, Serhiy Storchaka wrote:
>  data = b"\x43\x6c\x67\x75\x62\x61" # is there an easier way to
>  turn a hex dump into a bytes literal?  
> 
>  >>> bytes.fromhex('43 6c 67 75 62 61')  
> b'Clguba'

Very nice new functionality in Py3k, but 2.x doesn't seem to have such
a method. :-(

-tkc



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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 20:42, Tim Chase wrote:

On 2014-01-06 22:20, Serhiy Storchaka wrote:

data = b"\x43\x6c\x67\x75\x62\x61" # is there an easier way to
turn a hex dump into a bytes literal?


  >>> bytes.fromhex('43 6c 67 75 62 61')
b'Clguba'


Very nice new functionality in Py3k, but 2.x doesn't seem to have such
a method. :-(

-tkc



Seems like another mistake, that'll have to be regressed to make sure 
there is Python 2 and Python 3 compatibility, which can then be 
reintroduced into Python 2.8 so that it gets back into Python 3.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/2014 8:44 AM, Mark Lawrence wrote:

On 06/01/2014 12:39, Ned Batchelder wrote:


I'm not talking about the technical details of bytes and Unicode.  I'm
talking about making customers happy.



Simply scrap PEP 404


Not necessary.


and the currently unhappy customers will be happy
as they'll be free to do all the work they want on Python 2.8,


They are already free to do so, as long as they do not call the result 
'Python 2.8'.


> as my

understanding is that the vast majority of the Python core developers
won't do it for them.


Which is what some of them want and why they will never be happy.



--
Terry Jan Reedy

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/2014 10:10 AM, Ethan Furman wrote:


The argument is that a very important, if small, subset a data
manipulation become very painful in Py3.  Not impossible, and not
difficult, but painful because the mental model and the contortions
needed to get things to work don't sync up anymore.


Thank you for a succinct summary. I presume you are referring in part by 
bytes manipulations that would be easier with bytes.format. In

http://bugs.python.org/issue3982
Guido gave approval in principle to a minimal new method a year ago. The 
proponents failed to build on that to get anything in 3.4. Finally, 
however, Viktor Stinner has written a PEP

http://www.python.org/dev/peps/pep-0460/
so something might happen for 3.5.

--
Terry Jan Reedy

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

Re: class inheritance python2.7 vs python3.3

2014-01-06 Thread jwe . van . dijk

On Monday, 6 January 2014 18:14:08 UTC+1, [email protected]  wrote:
> I have problems with these two classes:
> 
> 
> 
> class LPU1():
> 
> def __init__(self, formula):
> 
> """
> 
> formula is a string that is parsed into a SymPy function
> 
> and several derived functions
> 
> """
> 
> self.formula = formula
> 
> ... ...
> 
> 
> 
> class LPU3(LPU1):
> 
> def __new__(self):
> 
> """
> 
> the same functions as LPU1 but some added functions
> 
> and some functions redefined
> 
> """
> 
> ... ...
> 
> 
> 
> if __name__ == '__main__:
> 
> y = y = 'x_0 * x_1 + x_2'
> 
> stats1 = LPU1(y)
> 
> stats3 = LPU3(y)
> 
> 
> 
> Worked perfectly on Python 2.7.5+ but on Python 3.3.2+ I get on 
> instantiatiating stat3:
> 
> TypeError: __new__() takes 1 positional argument but 2 were given
> 
> 
> 
> What am I doing wrong?
> 
> I must confess I am a bit out of my depth here so any explanation will be a 
> learning experience.
> 
> 
> 
> Many thanks, Janwillem

Thanks for all the contributions. I now have:
class LPU1(object):
def __init__(self, formula):
... ...
and
class LPU3(LPU1):
def __init__(self, y):
LPU1.__init__(self, y)
   ... ...

which gives the correct results both on 2.7 and 3.3.
Is that more or less good practice?
Now I stumble on a SymPy problem under 3.3 but that obviously is an other topic
Cheers, janwillem
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 20:49, Terry Reedy wrote:

On 1/6/2014 8:44 AM, Mark Lawrence wrote:

On 06/01/2014 12:39, Ned Batchelder wrote:


I'm not talking about the technical details of bytes and Unicode.  I'm
talking about making customers happy.



Simply scrap PEP 404


Not necessary.


and the currently unhappy customers will be happy
as they'll be free to do all the work they want on Python 2.8,


They are already free to do so, as long as they do not call the result
'Python 2.8'.

 > as my

understanding is that the vast majority of the Python core developers
won't do it for them.


Which is what some of them want and why they will never be happy.



I find all this intriguing.  People haven't found time to migrate from 
Python 2 to Python 3, but now intend finding time to produce a fork of 
Python 2 which will ease the migration to Python 3.  Have I got that 
correct?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/14 2:30 PM, Mark Janssen wrote:

Chris didn't say "bytes and ascii data", he said "bytes and TEXT".
Text != "ascii data", and the fact that some people apparently think it
does is pretty much the heart of the problem.


The heart of a different problem, not this one.  The problem I refer to is
that many binary formats have well-defined ascii-encoded text tidbits.


Really?  If people are using binary with "well-defined ascii-encoded
tidbits", they're doing something wrong.  Perhaps you think escape
characters "\n" are "well defined tidbits", but YOU WOULD BE WRONG.
The purpose of binary is to keep things raw.  WTF?  You guys are so
strange.




If you (generic you) don't get that, you'll have a bad time. I mean
*really*
get it, deep down in the bone. The long, bad habit of thinking as
ASCII-encoded bytes as text is the problem here.


I think the whole forking community is confused at because of your own
arrogance.  Foo(l)s.

markj



If you want to participate in this discussion, do so.  Calling people 
strange, arrogant, and fools with no technical content is just rude. 
Typing "YOU WOULD BE WRONG" in all caps doesn't count as technical content.


--
Ned Batchelder, http://nedbatchelder.com

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

Re: python finance

2014-01-06 Thread d ss

On Monday, January 6, 2014 12:06:45 PM UTC-5, Chris Angelico wrote:
> On Tue, Jan 7, 2014 at 3:58 AM, d ss  wrote:
> 
> > what the heck!
> 
> > who told you this is a spam!
> 
> > this is a call for cooperation and collaboration
> 
> > how retarded!
> 
> 
> 
> It is, at best, misdirected. There is a Python job board [1] where
> 
> these sorts of things can be posted, but the main mailing list isn't
> 
> the place for it.
> 
> 
> 
> However, if you want your posts to be seen as legitimate, I would
> 
> recommend putting a little more content into them, and putting some
> 
> effort into the quality of English. Most of us will just skip over
> 
> something that looks like unsolicited commercial email, if we even see
> 
> it at all (spam filtering is getting pretty effective these days).
> 
> 
> 
> ChrisA
> 
> 
> 
> [1] http://www.python.org/community/jobs/

thanks Chris, i am checking the link
i wrote just 2 words with a clear indicative title: "Python, Finance" which 
summarizes the following "if you are good in python and interested in applying 
your python knowledge to the field of finance then we may have a common 
interest in talking together" :D
that s it!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Gene Heskett

On Monday 06 January 2014 16:16:13 Terry Reedy did opine:

> On 1/6/2014 9:32 AM, Gene Heskett wrote:
> > And from my lurking here, its quite plain to me that 3.x python has a
> > problem with everyday dealing with strings.
> 
> Strings of what? And what specific 'everyday' problem are you referring
> to?

Strings start a new thread here at nominally weekly intervals.  Seems to me 
that might be usable info.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Tip the world over on its side and everything loose will land in Los 
Angeles.
-- Frank Lloyd Wright
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
 law-abiding citizens.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"

>> Really?  If people are using binary with "well-defined ascii-encoded
>> tidbits", they're doing something wrong.  Perhaps you think escape
>> characters "\n" are "well defined tidbits", but YOU WOULD BE WRONG.
>> The purpose of binary is to keep things raw.  WTF?

> If you want to participate in this discussion, do so.  Calling people
> strange, arrogant, and fools with no technical content is just rude. Typing
> "YOU WOULD BE WRONG" in all caps doesn't count as technical content.

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/14 12:50 PM, Steven D'Aprano wrote:

Ned Batchelder wrote:


You are still talking about whether Armin is right, and whether he
writes well, about flaws in his statistics, etc.  I'm talking about the
fact that an organization (Python core development) has a product
(Python 3) that is getting bad press.  Popular and vocal customers
(Armin, Kenneth, and others) are unhappy.  What is being done to make
them happy?  Who is working with them?  They are not unique, and their
viewpoints are not outliers.

I'm not talking about the technical details of bytes and Unicode.  I'm
talking about making customers happy.


Oh? How much did Armin pay for his Python support? If he didn't pay, he's
not a customer. He's a user.


I use the term "customer" in the larger sense of, "someone using your 
product that you are trying to please."  I'd like to think that an open 
source project with only users would treat them as customers.  Not in 
the sense of a legal obligation in exchange for money, but in the sense 
that the point of the work is to please them.




When something gets bad press, the normal process is to first determine just
how justified that bad press is. (Unless, of course, you're more interested
in just *covering it up* than fixing the problem.) The best solutions are:

- if the bad press is justified, admit it, and fix the problems;

- if the bad press is not justified, try to educate Armin (and others) so
they stop blaming Python for their own errors; try to counter their bad
press with good press; or ignore it, knowing that the internet is
notoriously fickle and in a week people will be hating on Go, or Ruby
instead.

But I get the idea from your post that you don't want to talk about the
technical details of bytes and Unicode, and by extension, whether Python 3
is better or worse than Python 2. That makes it impossible to determine how
valid the bad press is, which leaves us hamstrung. Our only responses are:

- Patronise him. "Yes yes, you poor little thing, we feel your pain. But
what can we do about it?"

- Abuse him and hope he shuts up.

- Give in to his (and by extension, everyone elses) complaints, whether
justified or not, and make Python worse.

- Counter his bad press with good press, and come across as arrogant idiots
by denying actual real problems (if any).

- Wait for the Internet to move on.



I was only avoiding talking about Unicode vs bytes because I'm not the 
one who needs a better way to do it, Armin and Kenneth are.  You seem to 
be arguing from the standpoint of, "I've never had problems, so there 
are no problems."


I suspect an undercurrent here is also the difference between writing 
Python 3 code, and writing code that can run on both Python 2 and 3.


In my original post, I provided two possible responses, one of which 
you've omitted: work with Armin to explain the easier way that he has 
missed.  It sounds like you think there isn't an easier way, and that's 
OK? I would love to see a Python 3 advocate work with Armin or Kenneth 
on the code that's caused them such pain, and find a way to make it good.


It's clear from other discussions happening elsewhere that there is the 
possibility of improving the situation, for example PEP 460 proposing 
"bytes % args" and "bytes.format(args)".  That's good.


--
Ned Batchelder, http://nedbatchelder.com

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

Re: "More About Unicode in Python 2 and 3"

>> Really?  If people are using binary with "well-defined ascii-encoded
>> tidbits", they're doing something wrong.  Perhaps you think escape
>> characters "\n" are "well defined tidbits", but YOU WOULD BE WRONG.
>> The purpose of binary is to keep things raw.  WTF?
>
> If you want to participate in this discussion, do so.  Calling people
> strange, arrogant, and fools with no technical content is just rude. Typing
> "YOU WOULD BE WRONG" in all caps doesn't count as technical content.

Ned -- IF YOU'RE A REAL PERSON -- you will see that several words
prior to that declaration, you'll find (or be able to arrange) the
proposition: "Escape characters are well-defined tidbits of binary
data is FALSE".

Now that is a technical point that i'm saying is simply the "way
things are" coming from the mass of experience held by the OS
community and the C programming community which is responsible for
much of the world's computer systems.  Do you have an argument against
it, or do you piss off and argue against anything I say?? Perhaps I
said it too loudly, and I take responsibility for that, but don't
claim I'm not making a technical point which seems to be at the heart
of all the confusion regarding python/python3 and str/unicode/bytes.

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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 21:17, Gene Heskett wrote:

On Monday 06 January 2014 16:16:13 Terry Reedy did opine:


On 1/6/2014 9:32 AM, Gene Heskett wrote:

And from my lurking here, its quite plain to me that 3.x python has a
problem with everyday dealing with strings.


Strings of what? And what specific 'everyday' problem are you referring
to?


Strings start a new thread here at nominally weekly intervals.  Seems to me
that might be usable info.

Cheers, Gene



That strikes me as being as useful as "The PEP 393 FSR is completely 
wrong but I'm not going to tell you why" approach.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/14 11:29 AM, Antoine Pitrou wrote:

Ned Batchelder  nedbatchelder.com> writes:


You can look through his problems and decide that he's "wrong," or that
he's "ranting," but that doesn't change the fact that Python 3 is
encountering friction.  What happens when a significant fraction of your
customers are "wrong"?


Well, yes, there is some friction and this is quite expectable, when
shipping incompatible changes. Other pieces of software have undergone a
similar process (e.g. Apache 1.x -> Apache 2.x).

(the alternative is to maintain a piece of software that sticks with obsolete
conventions, e.g. emacs)


Core developers: I thank you for the countless hours you have devoted to
building all of the versions of Python.  I'm sure in many ways it's a
thankless task.  But you have a problem.  What's the point in being
right if you end up with a product that people don't use?


People don't use? According to available figures, there are more downloads of
Python 3 than downloads of Python 2 (Windows installers, mostly):
http://www.python.org/webstats/

The number of Python 3-compatible packages has been showing a constant and
healthy increase for years:
http://dev.pocoo.org/~gbrandl/py3.html

And Dan's survey shows 77% of respondents think Python 3 wasn't a mistake:
https://wiki.python.org/moin/2.x-vs-3.x-survey


Maybe there are core developers who are trying hard to solve the
problems Kenneth and Armin are facing.  It would be great if that work
was more visible.  I don't see it, and apparently Armin doesn't either.


While this is being discussed:
https://mail.python.org/pipermail/python-dev/2014-January/130923.html

I would still point out that "Kenneth and Armin" are not the whole Python
community.


I never said they were the whole community, of course. But they are not 
outliers either. By your own statistics above, 23% of respondents think 
Python 3 was a mistake.  Armin and Kenneth are just two very visible people.



Your whole argument seems to be that a couple "revered" (!!)
individuals should see their complaints taken for granted. I am opposed to
rockstarizing the community.


I'm not creating rock stars.  I'm acknowledging that these two people 
are listened to by many others.  It sounds like part of your effort to 
avoid rockstars is to ignore any one person's specific feedback?  I must 
be misunderstanding what you mean.




Their contribution is always welcome, of course.

(as for network programming, the people working on and with asyncio don't
seem to find Python 3 terrible)


Some people don't have problems.  That doesn't mean that other people 
don't have problems.


You are being given detailed specific feedback from intelligent 
dedicated customers that many people listen to, and who are building 
important components of the ecosystem, and your response is, "sorry, you 
are wrong, it will be fine if I ignore you."  That's disheartening.




Regards

Antoine.


--
Ned Batchelder, http://nedbatchelder.com

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

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Devin Jeanpierre

On Mon, Jan 6, 2014 at 1:02 PM, Mark Lawrence  wrote:
> I find all this intriguing.  People haven't found time to migrate from
> Python 2 to Python 3, but now intend finding time to produce a fork of
> Python 2 which will ease the migration to Python 3.  Have I got that
> correct?

Keeping old, unsupported (by upstream) things up-to-date is a common
operation (e.g. this is what Red Hat does for an entire operating
system). It might take a few hours to backport a module or bugfix you
want, but updating an entire million-LOC codebase would take
significantly longer. Plus, if a benefit of backporting things is an
easier eventual migration to 3.x, it's killing two birds with one
stone.

At any rate it's not a possibility to sneer at and suggest is
improbable or a waste of time. It is a rational outcome for a codebase
of a large enough size.

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/14 4:33 PM, Mark Lawrence wrote:

On 06/01/2014 21:17, Gene Heskett wrote:

On Monday 06 January 2014 16:16:13 Terry Reedy did opine:


On 1/6/2014 9:32 AM, Gene Heskett wrote:

And from my lurking here, its quite plain to me that 3.x python has a
problem with everyday dealing with strings.


Strings of what? And what specific 'everyday' problem are you referring
to?


Strings start a new thread here at nominally weekly intervals.  Seems
to me
that might be usable info.

Cheers, Gene



That strikes me as being as useful as "The PEP 393 FSR is completely
wrong but I'm not going to tell you why" approach.



Please stop baiting people.

--
Ned Batchelder, http://nedbatchelder.com

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/2014 7:39 AM, Ned Batchelder wrote:


You are still talking about whether Armin is right, and whether he
writes well, about flaws in his statistics, etc.


That is how *I* decide whether someone is worth attending to. He failed.

> I'm talking about the fact that an organization

of volunteers


(Python core development) has a product


given away for free, with a liberal license that allows derivative products


(Python 3) that is getting bad press.


Inevitable and nothing new.


(Armin, Kenneth, and others) are unhappy.


There are many unhappy people in the world. Some will be unhappy no 
matter what.



What is being done to make them happy?


Huh? What are they doing to make core developers happy?


Who is working with them?


You? Really the wrong question. Which of 'them' is working with us -- in 
a respectful manner -- through established means? (See my response to 
Ethan about what 'unhappy customers' failed to do for a year.)



I'm talking about making customers happy.


Python has 'customers' around the world. I am more am more concerned 
with helping poor kids in Asia, Africa, and Latin America than with 
well-off professional developers in Latin-alphabet regions.


A certain person is unhappy with a feature of 3.3+. When we fixed the 
first ostensible problem he identified, without his help, he found other 
reasons to be unhappy with the feature. When we voluntarily fix more of 
the ostensible problems with Python 3, which we will, without help from 
most of the 'unhappy customers', I expect that some of them will also 
continue to be unhappy customers. Some of them are opposed to the 
fundamental changes in Python 3 and will never be happy with it.


--
Terry Jan Reedy

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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 21:42, Ned Batchelder wrote:

On 1/6/14 4:33 PM, Mark Lawrence wrote:

On 06/01/2014 21:17, Gene Heskett wrote:

On Monday 06 January 2014 16:16:13 Terry Reedy did opine:


On 1/6/2014 9:32 AM, Gene Heskett wrote:

And from my lurking here, its quite plain to me that 3.x python has a
problem with everyday dealing with strings.


Strings of what? And what specific 'everyday' problem are you referring
to?


Strings start a new thread here at nominally weekly intervals.  Seems
to me
that might be usable info.

Cheers, Gene



That strikes me as being as useful as "The PEP 393 FSR is completely
wrong but I'm not going to tell you why" approach.



Please stop baiting people.



What are you on about?  The comment has been made that "its quite plain 
to me that 3.x python has a problem with everyday dealing with strings". 
 Myself, Terry Reedy and Steven D'Aprano have all commented on this, 
asking for more data.  We've been given nothing, which is precisely what 
our resident unicode expert has given us.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"

Ned Batchelder  nedbatchelder.com> writes:
> 
> 
> I never said they were the whole community, of course. But they are not 
> outliers either. By your own statistics above, 23% of respondents think 
> Python 3 was a mistake.  Armin and Kenneth are just two very visible 
> people.

Indeed, they are two very visible people.

> I'm not creating rock stars.  I'm acknowledging that these two people 
> are listened to by many others.  It sounds like part of your effort to 
> avoid rockstars is to ignore any one person's specific feedback?  I must 
> be misunderstanding what you mean.

I am not trying to ignore "any one person's specific feedback". I am 
ignoring your claim that we should give Armin's blog posts an
extraordinary importance because he is "revered".

Speaking of which, posting blog articles is not the preferred way to
give feedback. There are ample community resources for that. I am
irritated that we are apparently supposed to be monitoring blog posts, 
Twitter feeds and whatnot for any sign of dissent, and immediately react
to a criticism that wasn't even voiced directly to us.

> You are being given detailed specific feedback from intelligent 
> dedicated customers that many people listen to,

Could you please stop talking about customers? We are not selling
Python to anyone (*). Writing open source software as a volunteer is 
not supposed to be a sacrificial activity where we will bow with
extreme diligence to the community's every outburst. Please try to
respect us.

((*) Wikipedia: "A customer (sometimes known as a client, buyer, or 
purchaser) is the recipient of a good, service, product, or idea,
obtained from a seller, vendor, or supplier for a monetary or other 
valuable consideration")

Regards

Antoine.

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/14 5:08 PM, Mark Lawrence wrote:

On 06/01/2014 21:42, Ned Batchelder wrote:

On 1/6/14 4:33 PM, Mark Lawrence wrote:

On 06/01/2014 21:17, Gene Heskett wrote:

On Monday 06 January 2014 16:16:13 Terry Reedy did opine:


On 1/6/2014 9:32 AM, Gene Heskett wrote:

And from my lurking here, its quite plain to me that 3.x python has a
problem with everyday dealing with strings.


Strings of what? And what specific 'everyday' problem are you
referring
to?


Strings start a new thread here at nominally weekly intervals.  Seems
to me
that might be usable info.

Cheers, Gene



That strikes me as being as useful as "The PEP 393 FSR is completely
wrong but I'm not going to tell you why" approach.



Please stop baiting people.



What are you on about?  The comment has been made that "its quite plain
to me that 3.x python has a problem with everyday dealing with strings".
  Myself, Terry Reedy and Steven D'Aprano have all commented on this,
asking for more data.  We've been given nothing, which is precisely what
our resident unicode expert has given us.



I'm on about your comment being a gratuitous jab at someone who isn't 
even participating in the thread.  Stop it.


--
Ned Batchelder, http://nedbatchelder.com

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/14 5:16 PM, Antoine Pitrou wrote:

Ned Batchelder  nedbatchelder.com> writes:



I never said they were the whole community, of course. But they are not
outliers either. By your own statistics above, 23% of respondents think
Python 3 was a mistake.  Armin and Kenneth are just two very visible
people.


Indeed, they are two very visible people.


I'm not creating rock stars.  I'm acknowledging that these two people
are listened to by many others.  It sounds like part of your effort to
avoid rockstars is to ignore any one person's specific feedback?  I must
be misunderstanding what you mean.


I am not trying to ignore "any one person's specific feedback". I am
ignoring your claim that we should give Armin's blog posts an
extraordinary importance because he is "revered".

Speaking of which, posting blog articles is not the preferred way to
give feedback. There are ample community resources for that. I am
irritated that we are apparently supposed to be monitoring blog posts,
Twitter feeds and whatnot for any sign of dissent, and immediately react
to a criticism that wasn't even voiced directly to us.


You are being given detailed specific feedback from intelligent
dedicated customers that many people listen to,


Could you please stop talking about customers? We are not selling
Python to anyone (*). Writing open source software as a volunteer is
not supposed to be a sacrificial activity where we will bow with
extreme diligence to the community's every outburst. Please try to
respect us.


I do respect you, and all the core developers.  As I've said elsewhere 
in the thread, I greatly appreciate everything you do.  I dedicate a 
great deal of time and energy to the Python community, primarily because 
of the amazing product that you have all built.


I've made my point as best as I can, I'll stop now.



((*) Wikipedia: "A customer (sometimes known as a client, buyer, or
purchaser) is the recipient of a good, service, product, or idea,
obtained from a seller, vendor, or supplier for a monetary or other
valuable consideration")

Regards

Antoine.





--
Ned Batchelder, http://nedbatchelder.com

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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 22:22, Ned Batchelder wrote:

On 1/6/14 5:08 PM, Mark Lawrence wrote:

On 06/01/2014 21:42, Ned Batchelder wrote:

On 1/6/14 4:33 PM, Mark Lawrence wrote:

On 06/01/2014 21:17, Gene Heskett wrote:

On Monday 06 January 2014 16:16:13 Terry Reedy did opine:


On 1/6/2014 9:32 AM, Gene Heskett wrote:

And from my lurking here, its quite plain to me that 3.x python
has a
problem with everyday dealing with strings.


Strings of what? And what specific 'everyday' problem are you
referring
to?


Strings start a new thread here at nominally weekly intervals.  Seems
to me
that might be usable info.

Cheers, Gene



That strikes me as being as useful as "The PEP 393 FSR is completely
wrong but I'm not going to tell you why" approach.



Please stop baiting people.



What are you on about?  The comment has been made that "its quite plain
to me that 3.x python has a problem with everyday dealing with strings".
  Myself, Terry Reedy and Steven D'Aprano have all commented on this,
asking for more data.  We've been given nothing, which is precisely what
our resident unicode expert has given us.



I'm on about your comment being a gratuitous jab at someone who isn't
even participating in the thread.  Stop it.



You arrogance really has no bounds.  If you'd have done the job that you 
should have done in the first place and stopped that blithering idiot 16 
months ago, we wouldn't still be putting up with him now.  To top that, 
you're now defending "customers" when you should be saying quite clearly 
that PEP 404 stands as is and THERE WILL BE NO PYTHON 2.8.  Have I made 
my message perfectly clear?


And as I started this thread, I'll say what I please, throwing my toys 
out of my pram in just the same way that your pal Armin is currently doing.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Suggested GUI framework for Mac and unix?

2014-01-06 Thread Russell E. Owen

I have a free cross-platform Python GUI application that has to run on 
Mac and linux. It is presently written in Tkinter, but for various 
reasons* it may be time to switch.

I've heard many good things about wxpython and qt, but not used either, 
and am wondering if somebody could tell me if either (or both) would 
meet the following needs:
-  Reliable on mac and linux. (I see that wxpython now runs under Cocoa 
but I've not seen any reports on how well that went.)
- Compatible with matplotlib.
- Able to display (grayscale) images with arbitrary zoom. I currently 
use PIL with Tkinter's Canvas widget for this.
- Compatible with a sound library for playing sound cues. I presently 
use pygame for this and have been considering switching to PySDL.
- Compatible with Twisted Framework.
- Prediction is hard, but indications of a long-term future would be a 
definite bonus.

-- Russell

*I have no wish to disparage Tkinter. I personally like it and am very 
grateful to the developers. However, several issues are driving me to 
look for alternatives:
* There is a known crashing bug in recent versions of Tcl/Tk that keeps 
me at 8.5.11. Unfortunately I've not found a workaround.
* Tcl/Tk 8.5.11 is not compatible with Mavericks unless one runs in 
32-bit mode.
* There are known issues with the Tcl/Tk event loop since the switch to 
Cocoa. These are unlikely to be fixed, though in many cases it is 
practical to work around them. This is more of a long-term worry than a 
concrete problem.

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

Re: "More About Unicode in Python 2 and 3"


Mark Lawrence  yahoo.co.uk> writes:
> [...]
> 
> And as I started this thread, I'll say what I please, throwing my toys 
> out of my pram in just the same way that your pal Armin is currently doing.

I'll join Ned here: please stop it. You are doing a disservice to
everyone.

Thanks in advance

Antoine.


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

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Nicholas Cole

I hardly know which of the various threads on this topic to reply to!

No one is taking Python 2.7 away from anyone.  It is going to be on the net
for years to come.  Goodness! I expect if I wanted to go and download
Python 1.5 I could find it easily enough.

Like everyone else, when Python 3 came out I was nervous.  A lot of my code
broke - but it broke for a good reason.  I had been being cavalier about
strings and ASCII and bytes.  A lot of my code was working by accident
rather than by design, or because my users had never fed it anything that
would make it fall over.  Of course, my first reaction was a defensive one,
but once I had got over that and got my head around Python 3's view of the
world, I was pleased I had.  I find writing in Python 3 leads to more
robust code.  I like the way it forces me to do the right thing, and I like
the way it raises errors if I try to get away with something I shouldn't.
Going back to Python 2 now feels a bit like stepping back to the seductive
and permissive hell of PHP in some ways!  If I could be sure that I was
coding just for me and not having to support things still running on Python
2, I would move to Python 3.3 and not look back.  Except, yes, there are
still libraries that haven't made the changeblast!

Python 2.7 is there if your software was written to run on the 2 series.  I
am sure it will either be distributed with (as default or option) major
operating systems for some time.  I am totally unpersuaded by the argument
that 'back porting' more and more into Python 2 will ease the transition.
 I think it will just use up developer time, and delay further the day when
releasing new code for Python 3 only becomes not only reasonable but the
natural and default choice.

I am really glad to see that at least one distribution of Linux is moving
to Python 3 as the default.  I'd much rather see developer time spent
improving Python 3 than managing a transition.

I realised when Python 3.0 came out that eventually I would have to move to
Python 3.  I spent the next release in a state of denial.  But I had years
to get used to it, and I'm glad I have.  It "feels" more robust.  Of
course, I haven't ported every little program: but no one is forcing me
too!

All of these threads are written as if everyone's code is about to be
broken.  It isn't.  But if you want the new features, you need to make a
move, and it is probably time to write all new code in Python 3. If there's
a dependency holding you back, then there will be a Python 2 interpreter
around to run your code.  That all seems pretty reasonable and
straightforward to me.

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

Re: Drawing shaded area depending on distance with latitude and altitude coordinate

2014-01-06 Thread Dave Angel

On Mon, 6 Jan 2014 12:08:19 -0800 (PST), Isaac Won 
 wrote:

dis1 = [[]]*1




for c in range(0,275):
dis1[0].append(dis[c])


So dis1 has 1 row in it. But contourf is expecting many rows, 
matching the length of lat.  I'm guessing you have to fill in the 
others. 




cs = plt.contourf(lon,lat,dis1)



TypeError: Length of x must be number of columns in z, and 

length of y must be number of rows.

That's only a tiny part of the error message.  Please post the whole 
traceback.  I made a guess here knowing nothing about these libraries 
you're using.


--
DaveA

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

Re: "More About Unicode in Python 2 and 3"


On 1/6/2014 11:29 AM, Antoine Pitrou wrote:


People don't use? According to available figures, there are more downloads of
Python 3 than downloads of Python 2 (Windows installers, mostly):
http://www.python.org/webstats/


While I would like the claim to be true, I do not see 2 versus 3 
downloads on that page. Did you mean another link?



The number of Python 3-compatible packages has been showing a constant and
healthy increase for years:
http://dev.pocoo.org/~gbrandl/py3.html


This looks like the beginning of a sigmoid adoption curve. I do not 
expect to see a peak of 100% unless and until old, dead, Python 2 only 
projects get purged (in some future decade, if ever).


--
Terry Jan Reedy

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

Re: Suggested GUI framework for Mac and unix?


On 06/01/2014 22:31, Russell E. Owen wrote:

I'm no expert on GUIs but I've just picked wxPython via the age old 
system of tossing a coin :)



I have a free cross-platform Python GUI application that has to run on
Mac and linux. It is presently written in Tkinter, but for various
reasons* it may be time to switch.

I've heard many good things about wxpython and qt, but not used either,
and am wondering if somebody could tell me if either (or both) would
meet the following needs:
-  Reliable on mac and linux. (I see that wxpython now runs under Cocoa
but I've not seen any reports on how well that went.)


I can't comment but there's bound to be data on either the wxpython 
development or users mailing lists.



- Compatible with matplotlib.


Demo here looks good 
http://eli.thegreenplace.net/2008/08/01/matplotlib-with-wxpython-guis/



- Able to display (grayscale) images with arbitrary zoom. I currently
use PIL with Tkinter's Canvas widget for this.
- Compatible with a sound library for playing sound cues. I presently
use pygame for this and have been considering switching to PySDL.
- Compatible with Twisted Framework.
- Prediction is hard, but indications of a long-term future would be a
definite bonus.


From wxpython.org "(25-Dec-2013) wxPython (classic) 3.0.0.0 has been 
released. No new features but lots of bug fixes in wxWidgets and of 
course the bump (finally!) up to 3.0."  See also 
http://wiki.wxpython.org/ProjectPhoenix which is the port of wxpython to 
support Python 3.  I'm not sure when it will be released by I believe 
we're talking months.




-- Russell




--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"

>> I would still point out that "Kenneth and Armin" are not the whole Python
>> community.
>
> I never said they were the whole community, of course. But they are not
> outliers either.  [...]
>
>> Your whole argument seems to be that a couple "revered" (!!)
>> individuals should see their complaints taken for granted. I am opposed to
>> rockstarizing the community.
>
> I'm not creating rock stars.  I'm acknowledging that these two people are
> listened to by many others.  It sounds like part of your effort to avoid
> rockstars is to ignore any one person's specific feedback?  I must be
> misunderstanding what you mean.

To Ned's defense, it doesn't always work to treat everyone in the
community as equal.  That's not to say that those two examples are the
most important, but some people work on core aspects of the field
which are critical for everything else to work properly.  Without
diving into it, one can't say whether Ned's intuition is wrong or not.

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

Re: "More About Unicode in Python 2 and 3"

On Tue, Jan 7, 2014 at 7:42 AM, Tim Chase  wrote:
> On 2014-01-06 22:20, Serhiy Storchaka wrote:
>>  data = b"\x43\x6c\x67\x75\x62\x61" # is there an easier way to
>>  turn a hex dump into a bytes literal?
>>
>>  >>> bytes.fromhex('43 6c 67 75 62 61')
>> b'Clguba'
>
> Very nice new functionality in Py3k, but 2.x doesn't seem to have such
> a method. :-(

Thanks, Serhiy. Very nice new functionality indeed, and not having it
in 2.x isn't a problem to me. That's exactly what I was looking for -
it doesn't insist on (or complain about) separators between bytes.
(Though the error from putting a space _inside_ a byte is a little
confusing. But that's trivial.)

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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 22:35, Antoine Pitrou wrote:


Mark Lawrence  yahoo.co.uk> writes:

[...]

And as I started this thread, I'll say what I please, throwing my toys
out of my pram in just the same way that your pal Armin is currently doing.


I'll join Ned here: please stop it. You are doing a disservice to
everyone.

Thanks in advance

Antoine.




I will for you as I have great respect for the amount of work that I've 
seen you do over the years that I've been using Python.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"

On Tue, Jan 7, 2014 at 8:32 AM, Mark Janssen  wrote:
>>> Really?  If people are using binary with "well-defined ascii-encoded
>>> tidbits", they're doing something wrong.  Perhaps you think escape
>>> characters "\n" are "well defined tidbits", but YOU WOULD BE WRONG.
>>> The purpose of binary is to keep things raw.  WTF?
>>
>> If you want to participate in this discussion, do so.  Calling people
>> strange, arrogant, and fools with no technical content is just rude. Typing
>> "YOU WOULD BE WRONG" in all caps doesn't count as technical content.
>
> Ned -- [chomp verbiage]

Mark, please watch your citations. Several (all?) of your posts in
this thread have omitted the line(s) at the top saying who you're
quoting. Have a look at my post here, and then imagine how confused
Mark Lawrence would be if I hadn't made it clear that I wasn't
addressing him.

Thanks!

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

Re: "More About Unicode in Python 2 and 3"


On 06/01/2014 22:41, Nicholas Cole wrote:

I hardly know which of the various threads on this topic to reply to!

No one is taking Python 2.7 away from anyone.  It is going to be on the
net for years to come.  Goodness! I expect if I wanted to go and
download Python 1.5 I could find it easily enough.

Like everyone else, when Python 3 came out I was nervous.  A lot of my
code broke - but it broke for a good reason.  I had been being cavalier
about strings and ASCII and bytes.  A lot of my code was working by
accident rather than by design, or because my users had never fed it
anything that would make it fall over.  Of course, my first reaction was
a defensive one, but once I had got over that and got my head around
Python 3's view of the world, I was pleased I had.  I find writing in
Python 3 leads to more robust code.  I like the way it forces me to do
the right thing, and I like the way it raises errors if I try to get
away with something I shouldn't. Going back to Python 2 now feels a bit
like stepping back to the seductive and permissive hell of PHP in some
ways!  If I could be sure that I was coding just for me and not having
to support things still running on Python 2, I would move to Python 3.3
and not look back.  Except, yes, there are still libraries that haven't
made the changeblast!

Python 2.7 is there if your software was written to run on the 2 series.
  I am sure it will either be distributed with (as default or option)
major operating systems for some time.  I am totally unpersuaded by the
argument that 'back porting' more and more into Python 2 will ease the
transition.  I think it will just use up developer time, and delay
further the day when releasing new code for Python 3 only becomes not
only reasonable but the natural and default choice.

I am really glad to see that at least one distribution of Linux is
moving to Python 3 as the default.  I'd much rather see developer time
spent improving Python 3 than managing a transition.
I realised when Python 3.0 came out that eventually I would have to move
to Python 3.  I spent the next release in a state of denial.  But I had
years to get used to it, and I'm glad I have.  It "feels" more robust.
  Of course, I haven't ported every little program: but no one is
forcing me too!

All of these threads are written as if everyone's code is about to be
broken.  It isn't.  But if you want the new features, you need to make a
move, and it is probably time to write all new code in Python 3. If
there's a dependency holding you back, then there will be a Python 2
interpreter around to run your code.  That all seems pretty reasonable
and straightforward to me.

Nicholas




The first sentence from the blog which gives this thread its title "It's 
becoming increasingly harder to have reasonable discussions about the 
differences between Python 2 and 3 because one language is dead and the 
other is actively developed".  Funny really as I see bug fixes going 
into Python 2.7 on a daily basis so I can only assume that their 
definition of dead is different to mine and presumably yours.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

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

Re: "More About Unicode in Python 2 and 3"

Terry Reedy  udel.edu> writes:
> 
> On 1/6/2014 11:29 AM, Antoine Pitrou wrote:
> 
> > People don't use? According to available figures, there are more
downloads of
> > Python 3 than downloads of Python 2 (Windows installers, mostly):
> > http://www.python.org/webstats/
> 
> While I would like the claim to be true, I do not see 2 versus 3 
> downloads on that page. Did you mean another link?

Just click on a recent month, scroll down to the "Total URLs By kB"
table, and compute the sum of the largest numbers for each Python
version.

Regards

Antoine.


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

Re: "More About Unicode in Python 2 and 3"

2014-01-06 Thread Ben Finney

Mark Lawrence  writes:

> You arrogance really has no bounds.  If you'd have done the job that
> you should have done in the first place and stopped that blithering
> idiot 16 months ago, we wouldn't still be putting up with him now.

That is a misdirection; Ned's request that you stop bad behaviour
(baiting known trolls into responding on a thread) is unrelated to
Armin's bad behaviour. Don't use the bad behaviour of others to justify
yours.

> And as I started this thread, I'll say what I please, throwing my toys
> out of my pram in just the same way that your pal Armin is currently
> doing.

We expect everyone to behave well, regardless of whether they start a
thread or not. Don't use the bad behaviour of others to justify yours.

We know you're better than this, Mark. Please stop.

-- 
 \   “To have the choice between proprietary software packages, is |
  `\  being able to choose your master. Freedom means not having a |
_o__)master.” —Richard M. Stallman, 2007-05-16 |
Ben Finney

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

Re: "More About Unicode in Python 2 and 3"

On Tue, Jan 7, 2014 at 7:32 AM, Antoine Pitrou  wrote:
> Chris Angelico  gmail.com> writes:
>>
>> On Tue, Jan 7, 2014 at 3:29 AM, Antoine Pitrou  pitrou.net>
> wrote:
>> > People don't use? According to available figures, there are more
> downloads of
>> > Python 3 than downloads of Python 2 (Windows installers, mostly):
>> > http://www.python.org/webstats/
>> >
>>
>> Unfortunately, that has a massive inherent bias, because there are
>> Python builds available in most Linux distributions - and stats from
>> those (like Debian's popcon) will be nearly as useless, because a lot
>> of them will install one or the other (probably 2.x) without waiting
>> for the user (so either they'll skew in favour of the one installed,
>> or in favour of the one NOT installed, because that's the only one
>> that'll be explicitly requested). It's probably fairly accurate for
>> Windows stats, though, since most people who want Python on Windows
>> are going to come to python.org for an installer.
>
> Agreed, but it's enough to rebut the claim that "people don't use
> Python 3". More than one million Python 3.3 downloads per month under
> Windows is a very respectable number (no 2.x release seems to reach
> that level).

Sure. The absolute number is useful; I just don't think the relative
number is - you started by talking about there being "more downloads
of Python 3 than downloads of Python 2", and it's that comparison that
I think is unfair. But the absolute numbers are definitely
significant. I'm not quite sure how to interpret the non-link lines in
[1] but I see the month of December showing roughly 1.2 million Python
3.3.3 downloads for Windows - interestingly, split almost fifty-fifty
between 64-bit and 32-bit installs - and just over one million Python
2.7.6 installs. That's one month, two million installations of Python.
That's 73,021 *per day* for the month of December. That is a lot of
Python.

ChrisA

[1] http://www.python.org/webstats/usage_201312.html#TOPURLS
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "More About Unicode in Python 2 and 3"