Re: RE Module Performance

[Antoon Pardon]

Op 26-07-13 15:21, wxjmfa...@gmail.com schreef:


Hint: To understand Unicode (and every coding scheme), you should
understand "utf". The how and the *why*.


No you don't. You are mixing the information with how the information
is coded. utf is like base64, a way of coding the information that is
usefull for storage or transfer. But once you have decode the byte 
stream, you no longer need any understanding of base64 to process your

information. Likewise, once you have decode the bytestream into uniocde
information you don't need knowledge of utf to process unicode strings.

--
Antoon Pardon



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

PyPI Notifier watches your requirements.txt files

[Cenk Altı]

Hello Python,

I would like tell you about my project that I have built on my spare time.

http://www.pypi-notifier.org/

Basically, you login with your GitHub account and select your Python
repositories which have a requirements.txt file. Then, it starts to watch
the dependencies listed in requirements.txt files. When a new version of a
dependency is released on PyPI you get an email.

Enjoy.
Cenk Alti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: RE Module Performance

[Antoon Pardon]

Op 28-07-13 20:19, Joshua Landau schreef:

On 28 July 2013 09:45, Antoon Pardon mailto:antoon.par...@rece.vub.ac.be>> wrote:

Op 27-07-13 20:21, wxjmfa...@gmail.com 
schreef:

utf-8 or any (utf) never need and never spend their time
in reencoding.


So? That python sometimes needs to do some kind of background
processing is not a problem, whether it is garbage collection,
allocating more memory, shufling around data blocks or reencoding a
string, that doesn't matter. If you've got a real world example where
one of those things noticeably slows your program down or makes the
program behave faulty then you have something that is worthy of
attention.


Somewhat off topic, but befitting of the triviality of this thread, do I
understand correctly that you are saying garbage collection never causes
any noticeable slowdown in real-world circumstances? That's not remotely
true.


No that is not what I am saying. But if jmf would be complaining about
garbage collection in an analog way as he is complaining about the FSR,
he wouldn't be complaining about real-world circumstances but about
theorectical possibilities and micro bench marks. In those circunstances
the "garbage collection problem" wouldn't be worthy of attention much.

--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list

Re: programming course

[Chris Angelico]

On Sat, Jul 27, 2013 at 1:28 PM,   wrote:
> Hi,
> A good step by step easy book on Python is: "Start Here: Python 3x 
> Programming Made Fun and Easier," at http://www.quantum-sight.com

This is a Usenet group and a mailing list, not a web forum. You do not
need to dig up a dozen ancient threads in order to advertise your
wares. And by the way, it's courteous to be up-front about (1) your
connection with what you're recommending, and (2) the fact that it's a
pay-for book.

One post, in a thread of its own, announcing the release of the book,
would be appropriate and on-topic. Just please don't reply to heaps of
old threads with commercial proposals :)

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

Re: RE Module Performance

[Antoon Pardon]

Op 28-07-13 21:30, wxjmfa...@gmail.com schreef:


To be short, this is *never* the FSR, always something
else.

Suggestion. Start by solving all these "micro-benchmarks".
all the memory cases. It a good start, no?



There is nothing to solve. Unicode doesn't force implementations
to use the same size of memory for strings of the same length.

So you pointing out examples of same length strings that don't
use the same size of memory doesn't point at something that
must be solved.

--
Antoon Pardon

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

Re: RE Module Performance

[Chris Angelico]

On Sun, Jul 28, 2013 at 11:14 PM, Joshua Landau  wrote:
> GC does have sometimes severe impact in memory-constrained environments,
> though. See http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/,
> about half-way down, specifically
> http://sealedabstract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-10.15.29-PM.png.
>
> The best verification of these graphs I could find was
> https://blog.mozilla.org/nnethercote/category/garbage-collection/, although
> it's not immediately clear in Chrome's and Opera's case mainly due to none
> of the benchmarks pushing memory usage significantly.
>
> I also don't quite agree with the first post (sealedabstract) because I get
> by *fine* on 2GB memory, so I don't see why you can't on a phone. Maybe IOS
> is just really heavy. Nonetheless, the benchmarks aren't lying.

The ultimate in non-managed memory (the opposite of a GC) would have
to be the assembly language programming I did in my earlier days,
firing up DEBUG.EXE and writing a .COM file that lived inside a single
64KB segment for everything (256-byte Program Segment Prefix, then
code, then initialized data, then uninitialized data and stack),
crashing the computer with remarkable ease. Everything "higher level"
than that (even malloc/free) has its conveniences and its costs,
usually memory wastage. If you malloc random-sized blocks, free them
at random, and ensure that your total allocated size stays below some
limit, you'll still eventually run yourself out of memory. This is
unsurprising. The only question is, how bad is the wastage and how
much time gets devoted to it?

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

Re: [Savoynet] G&S Opera Co: Pirates of Penzance

[Eric S. Johansson]

On Sun, 28 Jul 2013 19:49:07 -0400, Ethan Furman   
wrote:



On 07/28/2013 10:57 AM, Chris Angelico wrote:
.
.
.

Okay, how did you get confused that this was a Python List question?  ;)


got_a_little_list["victim must be found"] =  
http://www.youtube.com/watch?v=1NLV24qTnlg

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

MyOpenID.com no longer supported

[Ethan Furman]

Excerpt from http://meta.stackoverflow.com/q/190442/176681:

Janrain no longer actively supports MyOpenID, and announced on Twitter that 
their users should proceed with caution.

This decision was made by Janrain, [snip]

I know the Python bug tracker allows MyOpenID logins; if that is your only login method you should add another that 
doesn't depend on MyOpenID.


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

Re: MyOpenID.com no longer supported

[Antoine Pitrou]

Le Mon, 29 Jul 2013 00:55:53 -0700,
Ethan Furman  a écrit :
> Excerpt from http://meta.stackoverflow.com/q/190442/176681:
> 
> Janrain no longer actively supports MyOpenID, and announced on
> Twitter that their users should proceed with caution.
> 
> This decision was made by Janrain, [snip]
> 
> I know the Python bug tracker allows MyOpenID logins; if that is your
> only login method you should add another that doesn't depend on
> MyOpenID.

I don't understand. The tracker allows any (sufficently compliant)
OpenID provider, not just "MyOpenID" or
"MyCorporateOpenIDWithTrademarks".

Regards

Antoine.


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

substituting proxy

[Robin Becker]

Before attempting to reinvent the wheel has anyone created an http(s) proxy that 
can replace the content for specific requests.


Context: I have access to the client's test site, but a lot of the  requests are 
dynamic and save html complete etc etc doesn't work properly. In addition lots 
of the content comes from a cloud server which seems to object unless I take 
great care over spoofing of host names & referrers etc.


I would like to debug stuff we supply, but that's hard unless I have the whole 
kit & kaboodle. I thought a proxy that could substitute for our javascript 
file(s) might work.


Has anyone done this in twisted pymiproxy etc etc?
--
Robin Becker

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

Re: Configuraion to run pyhton script on ubuntu 12.04

[Jaiky]

Problem solved regarding cgi configuration on ubuntu 12.04 lts


Concept:-)
file used:-)
   /etc/apache2/httpd.conf  
   /etc/apache2/sites-available/default


steps done 1:-)

in /etc/apache2/httpd.conf 
added line 


#for link localhost/python2/hello.py   
ScriptAlias /python2/ /var/www/python2/  


AllowOverride None
Options +Indexes FollowSymLinks +ExecCGI   -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
###fro runing of python script
AddHandler cgi-script cgi pl mod_python .py
PythonHandler mod_python.publisher | .py
AddHandler mod_python .psp .psp_
PythonHandler mod_python.psp | .psp .psp
PythonDebug On


#

step done 2:-)

added line 

###fro runing of python script
AddHandler cgi-script cgi pl mod_python .py
PythonHandler mod_python.publisher | .py
AddHandler mod_python .psp .psp_
PythonHandler mod_python.psp | .psp .psp
PythonDebug On

between 


-
---
HERE I ADDED Line
-
-




-
---
HERE I ADDED Line
-
-

 



Step Done 3:-)

added line  
in /etc/apache2/mods-available/mod_python.conf

##mod_python.conf i created



AddHandler mod_python .py .psp
PythonHandler mod_python.publisher | .py
PythonHandler mod_python.psp | .psp







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

Re: Critic my module

[Schneider]

Hi,

lets uses the ls example:
the way you do it now implies, that you search your PATH variable until 
it finds a
program called 'ls'. So if we are able to change the PATH variable, and 
put out own
'ls' somewhere in the (new) paths, calling you ls() will execute 
whatever we want our

own  ls' to do.

Second remark: if the behavior of some tools is changed (for examples 
with using aliases)
we cannot expect the called tool (in the example: 'ls') to give the same 
output on

every system.

this can be avoided (mostly) by ensuring that the right program (in the 
example /bin/ls) is called, and not only ls.


bg,
Johannes

On 07/26/2013 12:39 PM, Devyn Collier Johnson wrote:


On 07/25/2013 09:58 AM, Schneider wrote:

Hi,

nice idea.

mybe -  for security reasons - you should ensure, that the right tool 
is called and not some tool put the path with the same name.


bg,
Johannes

Devyn Collier Johnson On Thu 25 Jul 2013 
03:24:30 PM CEST, Devyn Collier Johnson wrote:

Aloha Python Users!

   I made a Python3 module that allows users to use certain Linux
shell commands from Python3 more easily than using os.system(),
subprocess.Popen(), or subprocess.getoutput(). This module (once
placed with the other modules) can be used like this

import boash; boash.ls()

   I attached the module. I plan to release it on the Internet soon,
but feel free to use it now. It is licensed under LGPLv3.

   The name comes from combining "Boa" with "SHell". Notice that the
module's name almost looks like "BASH", a common Linux shell. The Boa
is a constrictor snake. This module makes Unix shells easier to use
via Python3. This brings the system shell closer to the Python shell.


Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com






--
GLOBE Development GmbH
Königsberger Strasse 260
48157 MünsterGLOBE Development GmbH
Königsberger Strasse 260
48157 Münster
0251/5205 390


What do you mean by that Schneider?

Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com



--
GLOBE Development GmbH
Königsberger Strasse 260
48157 MünsterGLOBE Development GmbH
Königsberger Strasse 260
48157 Münster
0251/5205 390

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

Re: Critic my module

[Devyn Collier Johnson]

On 07/29/2013 06:58 AM, Schneider wrote:

Hi,

lets uses the ls example:
the way you do it now implies, that you search your PATH variable 
until it finds a
program called 'ls'. So if we are able to change the PATH variable, 
and put out own
'ls' somewhere in the (new) paths, calling you ls() will execute 
whatever we want our

own  ls' to do.

Second remark: if the behavior of some tools is changed (for examples 
with using aliases)
we cannot expect the called tool (in the example: 'ls') to give the 
same output on

every system.

this can be avoided (mostly) by ensuring that the right program (in 
the example /bin/ls) is called, and not only ls.


bg,
Johannes

On 07/26/2013 12:39 PM, Devyn Collier Johnson wrote:


On 07/25/2013 09:58 AM, Schneider wrote:

Hi,

nice idea.

mybe -  for security reasons - you should ensure, that the right 
tool is called and not some tool put the path with the same name.


bg,
Johannes

Devyn Collier Johnson On Thu 25 Jul 2013 
03:24:30 PM CEST, Devyn Collier Johnson wrote:

Aloha Python Users!

   I made a Python3 module that allows users to use certain Linux
shell commands from Python3 more easily than using os.system(),
subprocess.Popen(), or subprocess.getoutput(). This module (once
placed with the other modules) can be used like this

import boash; boash.ls()

   I attached the module. I plan to release it on the Internet soon,
but feel free to use it now. It is licensed under LGPLv3.

   The name comes from combining "Boa" with "SHell". Notice that the
module's name almost looks like "BASH", a common Linux shell. The Boa
is a constrictor snake. This module makes Unix shells easier to use
via Python3. This brings the system shell closer to the Python shell.


Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com






--
GLOBE Development GmbH
Königsberger Strasse 260
48157 MünsterGLOBE Development GmbH
Königsberger Strasse 260
48157 Münster
0251/5205 390


What do you mean by that Schneider?

Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com





Thanks, good point. I will fix that. BTW, we bottom post on this mailing 
list.


Mahalo,

DCJ
--
http://mail.python.org/mailman/listinfo/python-list

Generating HTML

[Morten Guldager]

'Aloha Friends!

Still a bit new to python I'm afraid of choosing  an obsolete route when it
comes to generate some HTML in a Flask based micro web server.

I come from the Perl side where I have been using HTML::Element with great
success, and now I would like to know if something similar exists for
Python?

I would like to construct the complete page as a plain python structure and
then feed it to a function to get a chunk of HTML ready to send to the
client.

Something like:
  table_struct = ['table', ['tr', ['td', {class=>"red"}, "this is
red"],['td', {class=>"blue"}, "this is not red"]]]
  html = struct2html(table_struct)

Suggestions?


-- 
/Morten %-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: FSR and unicode compliance - was Re: RE Module Performance

[wxjmfauth]

Le dimanche 28 juillet 2013 22:52:16 UTC+2, Steven D'Aprano a écrit :
> On Sun, 28 Jul 2013 12:23:04 -0700, wxjmfauth wrote:
> 
> 
> 
> > Do not forget that à la "FSR" mechanism for a non-ascii user is
> 
> > *irrelevant*.
> 
> 
> 
> You have been told repeatedly, Python's internals are *full* of ASCII-
> 
> only strings.
> 
> 
> 
> py> dir(list)
> 
> ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', 
> 
> '__dir__', '__doc__', '__eq__', '__format__', '__ge__', 
> 
> '__getattribute__', '__getitem__', '__gt__', '__hash__', '__iadd__', 
> 
> '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', 
> 
> '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', 
> 
> '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', 
> 
> '__sizeof__', '__str__', '__subclasshook__', 'append', 'clear', 'copy', 
> 
> 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']
> 
> 
> 
> There's 45 ASCII-only strings right there, in only one built-in type, out 
> 
> of dozens. There are dozens, hundreds of ASCII-only strings in Python: 
> 
> builtin functions and classes, attributes, exceptions, internal 
> 
> attributes, variable names, and so on.
> 
> 
> 
> You already know this, and yet you persist in repeating nonsense.
> 
> 
> 
> 
> 
> -- 
> 
> Steven

3.2
>>> timeit.timeit("r = dir(list)")
22.300465007102908

3.3
>>> timeit.timeit("r = dir(list)")
27.13981129541519

For the record, I do not put your example to contradict
you. I was expecting such a result even before testing.

Now, if you do not understand why, you do not understand.
There nothing wrong.

jmf

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

Re: collections.Counter surprisingly slow

[Stefan Behnel]

Steven D'Aprano, 28.07.2013 22:51:
> Calling Counter ends up calling essentially this code:
> 
> for elem in iterable:
> self[elem] = self.get(elem, 0) + 1
> 
> (although micro-optimized), where "iterable" is your data (lines). 
> Calling the get method has higher overhead than dict[key], that will also 
> contribute.

It comes with a C accelerator (at least in Py3.4dev), but it seems like
that stumbles a bit over its own feet. The accelerator function special
cases the (exact) dict type, but the Counter class is a subtype of dict and
thus takes the generic path, which makes it benefit a bit less than possible.

Look for _count_elements() in

http://hg.python.org/cpython/file/tip/Modules/_collectionsmodule.c

Nevertheless, even the generic C code path looks fast enough in general. I
think the problem is just that the OP used Python 2.7, which doesn't have
this accelerator function.

Stefan


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

Re: collections.Counter surprisingly slow

[Joshua Landau]

On 29 July 2013 07:25, Serhiy Storchaka  wrote:

> 28.07.13 22:59, Roy Smith написав(ла):
>
>The input is an 8.8 Mbyte file containing about 570,000 lines (11,000
>> unique strings).
>>
>
> Repeat you tests with totally unique lines.


Counter is about ½ the speed of defaultdict in that case (as opposed to ⅓).


>  The full profiler dump is at the end of this message, but the gist of
>> it is:
>>
>
> Profiler affects execution time. In particular it slowdown Counter
> implementation which uses more function calls. For real world measurement
> use different approach.


Doing some re-times, it seems that his originals for defaultdict, exception
and Counter were about right. I haven't timed the other.


>  Why is count() [i.e. collections.Counter] so slow?
>>
>
> Feel free to contribute a patch which fixes this "wart". Note that Counter
> shouldn't be slowdowned on mostly unique data.


I find it hard to agree that counter should be optimised for the
unique-data case, as surely it's much more oft used when there's a point to
counting?

Also, couldn't Counter just extend from defaultdict?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: FSR and unicode compliance - was Re: RE Module Performance

[Chris Angelico]

On Mon, Jul 29, 2013 at 12:43 PM,   wrote:
> Le dimanche 28 juillet 2013 22:52:16 UTC+2, Steven D'Aprano a écrit :
> 3.2
 timeit.timeit("r = dir(list)")
> 22.300465007102908
>
> 3.3
 timeit.timeit("r = dir(list)")
> 27.13981129541519

3.2:
>>> len(dir(list))
42

3.3:
>>> len(dir(list))
45

Wonder if that might maybe have an impact on the timings.

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

Re: collections.Counter surprisingly slow

[Joshua Landau]

On 29 July 2013 12:46, Stefan Behnel  wrote:

> Steven D'Aprano, 28.07.2013 22:51:
> > Calling Counter ends up calling essentially this code:
> >
> > for elem in iterable:
> > self[elem] = self.get(elem, 0) + 1
> >
> > (although micro-optimized), where "iterable" is your data (lines).
> > Calling the get method has higher overhead than dict[key], that will also
> > contribute.
>
> It comes with a C accelerator (at least in Py3.4dev), but it seems like
> that stumbles a bit over its own feet. The accelerator function special
> cases the (exact) dict type, but the Counter class is a subtype of dict and
> thus takes the generic path, which makes it benefit a bit less than
> possible.
>
> Look for _count_elements() in
>
> http://hg.python.org/cpython/file/tip/Modules/_collectionsmodule.c
>
> Nevertheless, even the generic C code path looks fast enough in general. I
> think the problem is just that the OP used Python 2.7, which doesn't have
> this accelerator function.
>

# _count_elements({}, items), _count_elements(dict_subclass(), items),
Counter(items), defaultdict(int) loop with exception handling
# "items" is always 1m long with varying levels of repetition

>>> for items in randoms:
... helper.timeit(1), helper_subclass.timeit(1), counter.timeit(1),
default.timeit(1)
...
(0.18816172199876746, 0.4679023139997298, 0.96886425,
0.33518486200046027)
(0.2936601179990248, 0.605611173324, 1.1316078849995392,
0.46283868699902087)
(0.35396358400066674, 0.685048443998312, 1.2120939880005608,
0.5497965239992482)
(0.5337620789996436, 0.865870211392, 1.4507492869997805,
0.7772859329998028)
(0.745282343999861, 1.1455801379997865, 2.116569702000561,
1.3293145009993168)

:(

I have the helper but Counter is still slow. Is it not getting used for
some reason? It's not even as fast as helper on a dict's (direct, no
overridden methods) subclass.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: FSR and unicode compliance - was Re: RE Module Performance

[Heiko Wundram]

Am 29.07.2013 13:43, schrieb wxjmfa...@gmail.com:

3.2

timeit.timeit("r = dir(list)")

22.300465007102908

3.3

timeit.timeit("r = dir(list)")

27.13981129541519

For the record, I do not put your example to contradict
you. I was expecting such a result even before testing.

Now, if you do not understand why, you do not understand.
There nothing wrong.


Please give a single *proof* (not your gut feeling) that this is related 
to the FSR, and not rather due to other side-effects such as changes in 
how dir() works or (as Chris pointed out) due to more members on the 
list type in 3.3. If you can't or won't give that proof, there's no 
sense in continuing the discussion.


--
--- Heiko.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Generating HTML

[Burak Arslan]

Hi,

On 07/29/13 14:41, Morten Guldager wrote:
> Something like:
>   table_struct = ['table', ['tr', ['td', {class=>"red"}, "this is
> red"],['td', {class=>"blue"}, "this is not red"]]]
>   html = struct2html(table_struct)
>
> Suggestions?
>

See: http://lxml.de/lxmlhtml.html#creating-html-with-the-e-factory


Python 2.7.5 (default, Jul 16 2013, 00:38:32)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from lxml.html.builder import E
>>> e = E.html(
... E.head(
... E.title("Sample Html Page")
... ),
... E.body(
... E.div(
... E.h1("Hello World"),
... E.p(
... "lxml is quite nice when it comes to generating HTML "
... "from scratch"
... ),
... id="container",
... )
... )
... )
>>> from lxml.html import tostring
>>> print tostring(e, pretty_print=True)

Sample Html Page

Hello World
lxml is quite nice when it comes to generating HTML from scratch




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

Re: FSR and unicode compliance - was Re: RE Module Performance

[Devyn Collier Johnson]

On 07/29/2013 08:06 AM, Heiko Wundram wrote:

Am 29.07.2013 13:43, schrieb wxjmfa...@gmail.com:

3.2

timeit.timeit("r = dir(list)")

22.300465007102908

3.3

timeit.timeit("r = dir(list)")

27.13981129541519

For the record, I do not put your example to contradict
you. I was expecting such a result even before testing.

Now, if you do not understand why, you do not understand.
There nothing wrong.


Please give a single *proof* (not your gut feeling) that this is 
related to the FSR, and not rather due to other side-effects such as 
changes in how dir() works or (as Chris pointed out) due to more 
members on the list type in 3.3. If you can't or won't give that 
proof, there's no sense in continuing the discussion.


Wow! The RE Module thread I created is evolving into Unicode topics. 
That thread grew up so fast!


DCJ
--
http://mail.python.org/mailman/listinfo/python-list

AssertionError: Headers already set! Status: 500 Internal Server Error Content-Type: text/plain Content-Length: 59

[Jaiky]

learning  web concpt in python 


wrote code in /usr/lib/cgi-bin/hello_world.py

###
#!/usr/bin/env python

import webapp2


form ="""
http://www/google.com/search";>
  
  
"""


class MainPage(webapp2.RequestHandler):
def get(self):
self.response.out.write(form)



class TestHandler(webapp2.RequestHandler):
def get(self):
q=self.request.get("q")
self.response.out.write(q)

apps = webapp2.WSGIApplication([('/', 
MainPage),('/testform',TestHandler)],debug=True)


def main():
apps.run()


if __name__ == '__main__':
main()
 

###

when running this code on ubuntu 12.04 using command 

python hello_world.py

error obtained 


AssertionError: Headers already set!
Status: 500 Internal Server Error
Content-Type: text/plain
Content-Length: 59


##

want help please urgent  

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

Re: FSR and unicode compliance - was Re: RE Module Performance

[wxjmfauth]

Le lundi 29 juillet 2013 13:57:47 UTC+2, Chris Angelico a écrit :
> On Mon, Jul 29, 2013 at 12:43 PM,   wrote:
> 
> > Le dimanche 28 juillet 2013 22:52:16 UTC+2, Steven D'Aprano a écrit :
> 
> > 3.2
> 
>  timeit.timeit("r = dir(list)")
> 
> > 22.300465007102908
> 
> >
> 
> > 3.3
> 
>  timeit.timeit("r = dir(list)")
> 
> > 27.13981129541519
> 
> 
> 
> 3.2:
> 
> >>> len(dir(list))
> 
> 42
> 
> 
> 
> 3.3:
> 
> >>> len(dir(list))
> 
> 45
> 
> 
> 
> Wonder if that might maybe have an impact on the timings.
> 
> 
> 
> ChrisA

Good point. I stupidely forgot this.

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

Re: PyQt5 and virtualenv problem

[D. Xenakis]

Answer here: 
http://stackoverflow.com/questions/1961997/is-it-possible-to-add-pyqt4-pyside-packages-on-a-virtualenv-sandbox
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: FSR and unicode compliance - was Re: RE Module Performance

[wxjmfauth]

Le dimanche 28 juillet 2013 19:36:00 UTC+2, Terry Reedy a écrit :
> On 7/28/2013 11:52 AM, Michael Torrie wrote:
> 
> >
> 
> > 3. UTF-8 and UTF-16 encodings, being variable width encodings, mean that
> 
> > slicing a string would be very very slow,
> 
> 
> 
> Not necessarily so. See below.
> 
> 
> 
> > and that's unacceptable for
> 
> > the use cases of python strings.  I'm assuming you understand big O
> 
> > notation, as you talk of experience in many languages over the years.
> 
> > FSR and UTF-32 both are O(1) for slicing and lookups.
> 
> 
> 
> Slicing is at least O(m) where m is the length of the slice.
> 
> 
> 
> > UTF-8, 16 and any variable-width encoding are always O(n).\
> 
> 
> 
> I posted about a week ago, in response to Chris A., a method by which 
> 
> lookup for UTF-16 can be made O(log2 k), or perhaps more accurately, 
> 
> O(1+log2(k+1)), where k is the number of non-BMP chars in the string.
> 
> 
> 
> This uses an auxiliary array of k ints. An auxiliary array of n ints 
> 
> would make UFT-16 lookup O(1), but then one is using more space than 
> 
> with UFT-32. Similar comments apply to UTF-8.
> 
> 
> 
> The unicode standard says that a single strings should use exactly one 
> 
> coding scheme. It does *not* say that all strings in an application must 
> 
> use the same scheme. I just rechecked a few days ago. It also does not 
> 
> say that an application cannot associate additional data with a string 
> 
> to make processing of the string easier.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy

To my knowledge, the Unicode doc always speak about
the misc. utf* coding schemes in an "exclusive or" way.

Having multiple encoded strings is one thing. Manipulating
multiple encoded strings is something else.

Maybe the mistake was to not emphasize the fact that
one has to work with a unique set of encoded code points
(utf-8 or utf-16 or utf-32) because it was considered,
as to obvious one can not work properly with multiple
coding schemes.

You are also right in saying " ...application cannot associate
additional data...".
The doc does not specify it either. It is superfleous.


jmf

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

Re: FSR and unicode compliance - was Re: RE Module Performance

[wxjmfauth]

Le lundi 29 juillet 2013 13:57:47 UTC+2, Chris Angelico a écrit :
> On Mon, Jul 29, 2013 at 12:43 PM,   wrote:
> 
> > Le dimanche 28 juillet 2013 22:52:16 UTC+2, Steven D'Aprano a écrit :
> 
> > 3.2
> 
>  timeit.timeit("r = dir(list)")
> 
> > 22.300465007102908
> 
> >
> 
> > 3.3
> 
>  timeit.timeit("r = dir(list)")
> 
> > 27.13981129541519
> 
> 
> 
> 3.2:
> 
> >>> len(dir(list))
> 
> 42
> 
> 
> 
> 3.3:
> 
> >>> len(dir(list))
> 
> 45
> 
> 
> 
> Wonder if that might maybe have an impact on the timings.
> 
> 
> 
> ChrisA




class C:
a = 'abc'
b = 'def'
def aaa(self):
pass
def bbb(self):
pass
def ccc(self):
pass

if __name__ == '__main__':
import timeit
print(timeit.timeit("r = dir(C)", setup="from __main__ import C"))



>c:\python32\pythonw -u "timitmod.py"
15.258061416225663
>Exit code: 0
>c:\Python33\pythonw -u "timitmod.py"
17.052203122286194
>Exit code: 0


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

Re: dynamic type returning NameError:

[Tim O'Callaghan]

On Monday, July 29, 2013 1:43:39 AM UTC-4, Steven D'Aprano wrote:
> On Sun, 28 Jul 2013 18:38:10 -0700, Tim O'Callaghan wrote:
> 
> 
> 
> > Hi,
> 
> > 
> 
> > I hope that this hasn't been asked for the millionth time, so my
> 
> > apologies if it has.
> 
> [...]
> 
> > I hope that this was clear enough, apologies if it wasn't.
> 
> 
> 
> Clear as mud. 
> 
Alright, let me see if I can clear this up. And by the way, thanks for chiming 
in on this. It's appreciated. 

I have a 3rd party api definition that I'm using to generate python classes 
from so that I can access this api using python. The api definition currently 
changes, so what I've done is saved a local copy of the html (the api 
definition from the vendor) and screen scraped the categories, and methods for 
this api. So when the api changes, I can just get a fresh definition from the 
vendors site, parse the html, and generate the classes again. This screen scape 
is saved to a json object in the format I originally mentioned: 

returned from json from screen scrape: 
{"Whatever": [{"method1": "Some Default", "async": "True"},{"method2": "Some 
Other Default", "async": "True"}]} 


**note:

"method1": "Some Default"
"method2": "Some Other Default" 

are just dummy values. 

**

> 
> 
> > It's late(ish), I'm tired and borderline frustrated :)
> 
> 
> 
> I see your smiley, but perhaps you would get better results by waiting 
> 
> until you can make a better post.
> 
> 
> 
> It *really* helps if you post actual "working" (even if "working" means 
> 
> "fails in the way I said"), *short*, *simple* code. Often you'll find 
> 
> that trying to simplify the problem gives you the insight to solve the 
> 
> problem yourself.
> 
> 
> 
> http://www.sscce.org/
> 

I would normally post 'working' code, but I'm really not there yet. All I've 
been doing up until this point is basically proof of concept. 

> 
> 
> I'm going to try to guess what you're attempting, but I may get it 
> 
> completely wrong. Sorry if I do, but hopefully you'll get some insight 
> 
> even from my misunderstandings.
> 
> 
> 
> 
> 
> > I have a base class (BaseClass - we'll call it for this example) with an
> 
> > http call that i would like to inherit into a dynamic class at runtime.
> 
> > We'll call that method in BaseClass;  'request'.
> 
> 
> 
> If I read this literally, you want to do this:
> 
> 
> 
> class BaseClass(DynamicParent):
> 
> def request(self):
> 
> ...
> 
> 
> 
> except that DynamicParent isn't known until runtime. Am I close?

The parent is the stable/static part. That has the http request method to 
communicate with the vendor api. The request method in BaseClass creates the 
request(signs and authorizes the call).

Right now the BaseClass.request("api_call_to_vendor") will work and return 
data, but again I would like to separate each api category into classes with 
the appropriate methods. 

> 
> Obviously the above syntax won't work, but you can use a factory:
> 
> 
> 
> def make_baseclass(parent):
> 
> class BaseClass(parent):
> 
> def request(self):
> 
> ...
> 
> return BaseClass
> 
> 
> 
> class Spam: ...
> 
> 
> 
> BaseClass = make_baseclass(Spam)
> 
> 
> 
> 
> 
> Or you can use the type() constructor directly:
> 
> 
> 
> BaseClass = type('BaseClass', (Spam,), dict_of_methods_and_stuff)
> 
This, on the surface is what I'm after. Except the 'dict_of_methods_and_stuff' 
call would be something like this:

Vendor_API_Cateogry = type("Vendor_API_Category", (BaseClass,), 
{"api_call_from_vendors_category": 
"call_supers_request_method_passing_in_vendor_call"})

resulting in a call something like this:

vendor_category = Vendor_API_Category()
vendor_category.api_call_from_vendors_category()

> 
> which is probably far less convenient. But all this assumes I read you 
> 
> literally, and reading on, I don't think that's what you are after.
> 
> 
> 
> 
> 
> > I have a dictionary(json) of key (class name): value(method) that I
> 
> > would like to create inheriting this 'request' method from the
> 
> > BaseClass. So the derived class would look something like this
> 
> > 
> 
> > definition in json:
> 
> > {"Whatever": [{"method1": "Some Default", "async": True},{"method2":
> 
> > "Some Other Default", "async": True}]}
> 
> 
> 
> 
> 
> Pure gobbledygook to me. I don't understand what you're talking about, 
> 
> how does a derived class turn into JSON? (Could be worse, it could be 
> 
> XML.) Is BaseClass the "derived class", or are you talking about 
> 
> inheriting from BaseClass? What's "Some Default"? It looks like a string, 
> 
> and it certainly isn't a valid method name, not with a space in it.
> 
> 
> 
> Where did async and method2 come from? How do these things relate to 
> 
> "request" you talk about above? I think you're too close to the problem 
> 
> and don't realise that others don't sharing your knowledge of the problem.

Agreed. 

> 
> But, moving along, if I've understood you correctly, I don't think 
> 
> inherit

Re: FSR and unicode compliance - was Re: RE Module Performance

[Chris Angelico]

On Mon, Jul 29, 2013 at 3:20 PM,   wrote:
>>c:\python32\pythonw -u "timitmod.py"
> 15.258061416225663
>>Exit code: 0
>>c:\Python33\pythonw -u "timitmod.py"
> 17.052203122286194
>>Exit code: 0

>>> len(dir(C))

Did you even think to check that before you posted timings?

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

Unexpected results comparing float to Fraction

[Steven D'Aprano]

Comparing floats to Fractions gives unexpected results:

# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False

but:

py> 1/3 == float(Fraction(1, 3))
True


I expected that float-to-Fraction comparisons would convert the Fraction 
to a float, but apparently they do the opposite: they convert the float 
to a Fraction:

py> Fraction(1/3)
Fraction(6004799503160661, 18014398509481984)


Am I the only one who is surprised by this? Is there a general rule for 
which way numeric coercions should go when doing such comparisons?


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[Ian Kelly]

On Mon, Jul 29, 2013 at 9:43 AM, Steven D'Aprano
 wrote:
> Comparing floats to Fractions gives unexpected results:
>
> # Python 3.3
> py> from fractions import Fraction
> py> 1/3 == Fraction(1, 3)
> False
>
> but:
>
> py> 1/3 == float(Fraction(1, 3))
> True
>
>
> I expected that float-to-Fraction comparisons would convert the Fraction
> to a float, but apparently they do the opposite: they convert the float
> to a Fraction:
>
> py> Fraction(1/3)
> Fraction(6004799503160661, 18014398509481984)
>
>
> Am I the only one who is surprised by this? Is there a general rule for
> which way numeric coercions should go when doing such comparisons?

Any float can be precisely represented as a Fraction.  Not so in the
other direction.  So from that standpoint it makes sense to me to cast
to Fraction when comparing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MyOpenID.com no longer supported

[Ethan Furman]

On 07/29/2013 02:11 AM, Antoine Pitrou wrote:

Le Mon, 29 Jul 2013 00:55:53 -0700,
Ethan Furman  a écrit :

Excerpt from http://meta.stackoverflow.com/q/190442/176681:

Janrain no longer actively supports MyOpenID, and announced on
Twitter that their users should proceed with caution.

This decision was made by Janrain, [snip]

I know the Python bug tracker allows MyOpenID logins; if that is your
only login method you should add another that doesn't depend on
MyOpenID.


I don't understand. The tracker allows any (sufficently compliant)
OpenID provider, not just "MyOpenID" or
"MyCorporateOpenIDWithTrademarks".


That is true, but if your OpenID provider is MyOpenID (as mine was) then it 
would be wise to get another.

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

Re: Unexpected results comparing float to Fraction

[MRAB]

On 29/07/2013 16:43, Steven D'Aprano wrote:

Comparing floats to Fractions gives unexpected results:

# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False

but:

py> 1/3 == float(Fraction(1, 3))
True


I expected that float-to-Fraction comparisons would convert the Fraction
to a float, but apparently they do the opposite: they convert the float
to a Fraction:

py> Fraction(1/3)
Fraction(6004799503160661, 18014398509481984)


Am I the only one who is surprised by this? Is there a general rule for
which way numeric coercions should go when doing such comparisons?


I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
--
http://mail.python.org/mailman/listinfo/python-list

What do you do when a library is outdated?

[Matt]

I'm fairly new to python but have experience in other languages. What do you 
generally do when a library is outdated? I asked a question on a few forums and 
everyone has been pointing me to Mechanize, but it will not work with 3.3 

What do you do? 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to package embedded python?

[David M. Cotter]

nooobody knw
the trouble a s...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[Chris Angelico]

On Mon, Jul 29, 2013 at 5:09 PM, MRAB  wrote:
> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
> are approximate anyway, and the float value 1/3 is more likely to be
> Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).

At what point should it become Fraction(1, 3)?

>>> Fraction(0.3)
Fraction(5404319552844595, 18014398509481984)
>>> Fraction(0.33)
Fraction(5944751508129055, 18014398509481984)
>>> Fraction(0.333)
Fraction(5998794703657501, 18014398509481984)
>>> Fraction(0.333)
Fraction(6004798902680711, 18014398509481984)
>>> Fraction(0.33)
Fraction(6004799502560181, 18014398509481984)
>>> Fraction(0.3)
Fraction(6004799503160061, 18014398509481984)
>>> Fraction(0.3)
Fraction(6004799503160661, 18014398509481984)

Rounding off like that is a job for a cool library function (one of
which was mentioned on this list a little while ago, I believe), but
not IMO for the Fraction constructor.

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

Re: What do you do when a library is outdated?

[Chris Angelico]

On Mon, Jul 29, 2013 at 5:14 PM, Matt  wrote:
> I'm fairly new to python but have experience in other languages. What do you 
> generally do when a library is outdated? I asked a question on a few forums 
> and everyone has been pointing me to Mechanize, but it will not work with 3.3
>
> What do you do?

Depends what you mean by "outdated". Lots of things don't _need_ to be
up-to-date to be useful, and often, using the very latest version of
something just makes it hard to deploy (look at Debian and Red Hat,
both of which maintain support for a long time). If there's actually a
problem with something not being able to cope with current systems (eg
something that's designed to communicate with Windows and can't talk
to Win 8), then you go looking for a replacement package that can use
the latest, or possibly you write it yourself.

But my crystal ball tells me you're not asking about that, but rather
about a module that was written for Python 2 and hasn't been ported to
Python 3. (Usually there won't be other issues; if something breaks
between Py3.2 and Py3.3, it'll be easily fixed.) There are a few
options:

1) Talk to the author/maintainer. Explain that you want to use his/her
code with Python 3 but can't. Often, the only reason something isn't
ported is because of a perceived lack of interest.
2) Run the module code through the 2to3 utility. That might even be
all you need to do.
3) Port it yourself. Start with 2to3, and then work through any
problems you have. I would recommend getting to know the module on
Python 2 first, so you have a chance of knowing what it ought to be
doing.

You aren't the first to inquire about this. A quick Google search for
'mechanize python 3' brought this up:
http://web.cecs.pdx.edu/~adevore/mechanize/

Also, poking around a bit shows recommendations for the lxml and
requests modules, which may be able to do what you want.

So to answer your general question: Work, sometimes lots of work
(though not always). But for Mechanize specifically, Requests may be
your best bet.

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

Re: FSR and unicode compliance - was Re: RE Module Performance

[wxjmfauth]

Le lundi 29 juillet 2013 16:49:34 UTC+2, Chris Angelico a écrit :
> On Mon, Jul 29, 2013 at 3:20 PM,   wrote:
> 
> >>c:\python32\pythonw -u "timitmod.py"
> 
> > 15.258061416225663
> 
> >>Exit code: 0
> 
> >>c:\Python33\pythonw -u "timitmod.py"
> 
> > 17.052203122286194
> 
> >>Exit code: 0
> 
> 
> 
> >>> len(dir(C))
> 
> 
> 
> Did you even think to check that before you posted timings?
> 
> 
> 
> ChrisA

Boum, no! the diff is one.
I have however noticed, I can increase the number
of attributes (ascii), the timing differences
is very well marked.
I do not draw conclusions. Such a factor for one
unit

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

Re: AssertionError: Headers already set! Status: 500 Internal Server Error Content-Type: text/plain Content-Length: 59

[Terry Reedy]

On 7/29/2013 8:55 AM, Jaiky wrote:

learning  web concpt in python
wrote code in /usr/lib/cgi-bin/hello_world.py

###
#!/usr/bin/env python

import webapp2


This is an external package.


form ="""
 http://www/google.com/search";>
   
   
 """

class MainPage(webapp2.RequestHandler):
 def get(self):
 self.response.out.write(form)

class TestHandler(webapp2.RequestHandler):
 def get(self):
 q=self.request.get("q")
 self.response.out.write(q)

apps = webapp2.WSGIApplication([('/', 
MainPage),('/testform',TestHandler)],debug=True)

def main():
 apps.run()

if __name__ == '__main__':
 main()
###

when running this code on ubuntu 12.04 using command

python hello_world.py

error obtained

AssertionError: Headers already set!


This all comes from webapp2. You should never see assertion error. 
Report to authors or ask on webapp2 mailing list if there is one.



Status: 500 Internal Server Error
Content-Type: text/plain
Content-Length: 59


You should have made subject line something  like
"Webapp2: AssertionError"
as only someone familiar with webapp2 could give you any help.

--
Terry Jan Reedy

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

Re: What do you do when a library is outdated?

[Matt]

On Monday, July 29, 2013 12:34:08 PM UTC-4, Chris Angelico wrote:
> On Mon, Jul 29, 2013 at 5:14 PM, Matt  wrote:
> 
> > I'm fairly new to python but have experience in other languages. What do 
> > you generally do when a library is outdated? I asked a question on a few 
> > forums and everyone has been pointing me to Mechanize, but it will not work 
> > with 3.3
> 
> >
> 
> > What do you do?
> 
> 
> 
> Depends what you mean by "outdated". Lots of things don't _need_ to be
> 
> up-to-date to be useful, and often, using the very latest version of
> 
> something just makes it hard to deploy (look at Debian and Red Hat,
> 
> both of which maintain support for a long time). If there's actually a
> 
> problem with something not being able to cope with current systems (eg
> 
> something that's designed to communicate with Windows and can't talk
> 
> to Win 8), then you go looking for a replacement package that can use
> 
> the latest, or possibly you write it yourself.
> 
> 
> 
> But my crystal ball tells me you're not asking about that, but rather
> 
> about a module that was written for Python 2 and hasn't been ported to
> 
> Python 3. (Usually there won't be other issues; if something breaks
> 
> between Py3.2 and Py3.3, it'll be easily fixed.) There are a few
> 
> options:
> 
> 
> 
> 1) Talk to the author/maintainer. Explain that you want to use his/her
> 
> code with Python 3 but can't. Often, the only reason something isn't
> 
> ported is because of a perceived lack of interest.
> 
> 2) Run the module code through the 2to3 utility. That might even be
> 
> all you need to do.
> 
> 3) Port it yourself. Start with 2to3, and then work through any
> 
> problems you have. I would recommend getting to know the module on
> 
> Python 2 first, so you have a chance of knowing what it ought to be
> 
> doing.
> 
> 
> 
> You aren't the first to inquire about this. A quick Google search for
> 
> 'mechanize python 3' brought this up:
> 
> http://web.cecs.pdx.edu/~adevore/mechanize/
> 
> 
> 
> Also, poking around a bit shows recommendations for the lxml and
> 
> requests modules, which may be able to do what you want.
> 
> 
> 
> So to answer your general question: Work, sometimes lots of work
> 
> (though not always). But for Mechanize specifically, Requests may be
> 
> your best bet.
> 
> 
> 
> ChrisA

I appreciate this. I did not know of 2to3, and I am going to give that a shot 
right now. Thank you!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[MRAB]

On 29/07/2013 17:20, Chris Angelico wrote:

On Mon, Jul 29, 2013 at 5:09 PM, MRAB  wrote:

I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).


At what point should it become Fraction(1, 3)?


When the error drops below a certain threshold.


Fraction(0.3)

Fraction(5404319552844595, 18014398509481984)

Fraction(0.33)

Fraction(5944751508129055, 18014398509481984)

Fraction(0.333)

Fraction(5998794703657501, 18014398509481984)

Fraction(0.333)

Fraction(6004798902680711, 18014398509481984)

Fraction(0.33)

Fraction(6004799502560181, 18014398509481984)

Fraction(0.3)

Fraction(6004799503160061, 18014398509481984)

Fraction(0.3)

Fraction(6004799503160661, 18014398509481984)

Rounding off like that is a job for a cool library function (one of
which was mentioned on this list a little while ago, I believe), but
not IMO for the Fraction constructor.



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

Re: Unexpected results comparing float to Fraction

[Ian Kelly]

On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico  wrote:
> On Mon, Jul 29, 2013 at 5:09 PM, MRAB  wrote:
>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>> are approximate anyway, and the float value 1/3 is more likely to be
>> Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
>
> At what point should it become Fraction(1, 3)?

At the point where the float is exactly equal to the value you get
from the floating-point division 1/3.  If it's some other float then
the user didn't get there by entering 1/3, so it's not worth trying to
pretend that they did.

We do a similar rounding when formatting floats to strings, but in
that case one only has to worry about divisors that are powers of 10.
I imagine it's going to take more time to find the correct fraction
when any pair of relatively prime integers can be a candidate
numerator and denominator.  Additionally, the string rounding only
occurs when the float is being formatted for display; we certainly
don't do it as the result of numeric operations where it could result
in loss of precision.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[MRAB]

On 29/07/2013 17:40, Ian Kelly wrote:

On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico  wrote:

On Mon, Jul 29, 2013 at 5:09 PM, MRAB  wrote:

I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).


At what point should it become Fraction(1, 3)?


At the point where the float is exactly equal to the value you get
from the floating-point division 1/3.  If it's some other float then
the user didn't get there by entering 1/3, so it's not worth trying to
pretend that they did.


I thought that you're not meant to check for equality when using floats.


We do a similar rounding when formatting floats to strings, but in
that case one only has to worry about divisors that are powers of 10.
I imagine it's going to take more time to find the correct fraction
when any pair of relatively prime integers can be a candidate
numerator and denominator.  Additionally, the string rounding only
occurs when the float is being formatted for display; we certainly
don't do it as the result of numeric operations where it could result
in loss of precision.



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

Re: Unexpected results comparing float to Fraction

[Terry Reedy]

On 7/29/2013 11:50 AM, Ian Kelly wrote:

On Mon, Jul 29, 2013 at 9:43 AM, Steven D'Aprano
 wrote:

Comparing floats to Fractions gives unexpected results:

# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False

but:

py> 1/3 == float(Fraction(1, 3))
True


I expected that float-to-Fraction comparisons would convert the Fraction
to a float, but apparently they do the opposite: they convert the float
to a Fraction:

py> Fraction(1/3)
Fraction(6004799503160661, 18014398509481984)


Am I the only one who is surprised by this? Is there a general rule for
which way numeric coercions should go when doing such comparisons?


Any float can be precisely represented as a Fraction.  Not so in the
other direction.


In other words, there can be multiple unequal Franctions that have the 
same float value: for instance, Fraction(1,3) and 
Fraction(6004799503160661, 18014398509481984)


> So from that standpoint it makes sense to me to cast to
> Fraction when comparing.

Otherwise, == becomes non-transitive

--
Terry Jan Reedy

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

Re: Unexpected results comparing float to Fraction

[Chris Angelico]

On Mon, Jul 29, 2013 at 5:40 PM, Ian Kelly  wrote:
> On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico  wrote:
>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB  wrote:
>>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>>> are approximate anyway, and the float value 1/3 is more likely to be
>>> Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
>>
>> At what point should it become Fraction(1, 3)?
>
> At the point where the float is exactly equal to the value you get
> from the floating-point division 1/3.  If it's some other float then
> the user didn't get there by entering 1/3, so it's not worth trying to
> pretend that they did.
>
> We do a similar rounding when formatting floats to strings, but in
> that case one only has to worry about divisors that are powers of 10.
> I imagine it's going to take more time to find the correct fraction
> when any pair of relatively prime integers can be a candidate
> numerator and denominator.

I imagine it is, and that's where the problem comes in. The true value
is somewhere between (X-0.5)/2**n and (X+0.5)/2**n, or whatever the
actual range is, and finding a "nice" fraction in that range isn't an
instant and direct translation. It's a useful feature, but not IMO
necessary for the constructor.

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

Re: What do you do when a library is outdated?

[Terry Reedy]

On 7/29/2013 12:14 PM, Matt wrote:

I'm fairly new to python but have experience in other languages. What
do you generally do when a library is outdated? I asked a question on
a few forums and everyone has been pointing me to Mechanize, but it
will not work with 3.3

What do you do?


Update it yourself, ask someone else to update it, or use something else.

Or regress to an older Python that it will work with.



--
Terry Jan Reedy

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

Re: collections.Counter surprisingly slow

[Ian Kelly]

On Mon, Jul 29, 2013 at 5:49 AM, Joshua Landau  wrote:
> Also, couldn't Counter just extend from defaultdict?

It could, but I expect the C helper function in 3.4 will be faster
since it doesn't even need to call __missing__ in the first place.
And the cost (both in terms of maintenance and run-time) of adding
defaultdict to the Counter MRO just to reuse one tiny __missing__
method seems questionable, especially after taking into account that
the constructor signature is incompatible.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[Steven D'Aprano]

On Mon, 29 Jul 2013 17:48:21 +0100, MRAB wrote:

> On 29/07/2013 17:20, Chris Angelico wrote:
>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB 
>> wrote:
>>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>>> are approximate anyway, and the float value 1/3 is more likely to be
>>> Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
>>
>> At what point should it become Fraction(1, 3)?
>>
> When the error drops below a certain threshold.

Good plan! I pick a threshold of 42.7. Anyone got a better threshold?

*wink*



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[Steven D'Aprano]

On Mon, 29 Jul 2013 13:08:20 -0400, Terry Reedy wrote:

> In other words, there can be multiple unequal Franctions that have the
> same float value: for instance, Fraction(1,3) and
> Fraction(6004799503160661, 18014398509481984)
> 
>  > So from that standpoint it makes sense to me to cast to Fraction when
>  > comparing.
> 
> Otherwise, == becomes non-transitive

This is Python, and we can make __eq__ methods that do anything, 
including be non-transitive, non-reflexive, and nonsensical if we like :-)

But I take your point, and that makes sense.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[Ian Kelly]

On Mon, Jul 29, 2013 at 11:04 AM, MRAB  wrote:
> On 29/07/2013 17:40, Ian Kelly wrote:
>> At the point where the float is exactly equal to the value you get
>> from the floating-point division 1/3.  If it's some other float then
>> the user didn't get there by entering 1/3, so it's not worth trying to
>> pretend that they did.
>>
> I thought that you're not meant to check for equality when using floats.

Equality checking is useful for floats when there is exactly one value
that you want to test for as in this case, as opposed to a range of
approximate values that are considered to be equal within rounding
error.  There is exactly one float that the expression 0.1 evaluates
to, and although it's not equal to the decimal 0.1, it is the only
float that we want to format as "0.1".  The immediately preceding and
following floats are 0.0 and 0.10002, and
they are formatted as such because they're not equal to the float that
you get from 0.1.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[Rotwang]

On 29/07/2013 17:40, Ian Kelly wrote:

On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico  wrote:

On Mon, Jul 29, 2013 at 5:09 PM, MRAB  wrote:

I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).


At what point should it become Fraction(1, 3)?


At the point where the float is exactly equal to the value you get
from the floating-point division 1/3.


But the interpreter has no way of knowing that the value 1/3 that's been 
passed to the Fraction constructor was obtained from the division 1/3, 
rather than, say, 11/30 or 
6004799503160661/18014398509481984. How do you propose the constructor 
should decide between the many possible fractions that round to the same 
float, if not by choosing the one that evaluates to it exactly?


Personally the behaviour in the OP is exactly what I would expect.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[Rotwang]

On 29/07/2013 17:20, Chris Angelico wrote:

On Mon, Jul 29, 2013 at 5:09 PM, MRAB  wrote:

I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).


At what point should it become Fraction(1, 3)?


Fraction(0.3)

Fraction(5404319552844595, 18014398509481984)

Fraction(0.33)

Fraction(5944751508129055, 18014398509481984)

Fraction(0.333)

Fraction(5998794703657501, 18014398509481984)

Fraction(0.333)

Fraction(6004798902680711, 18014398509481984)

Fraction(0.33)

Fraction(6004799502560181, 18014398509481984)

Fraction(0.3)

Fraction(6004799503160061, 18014398509481984)

Fraction(0.3)

Fraction(6004799503160661, 18014398509481984)

Rounding off like that is a job for a cool library function (one of
which was mentioned on this list a little while ago, I believe), but
not IMO for the Fraction constructor.


How about this?

>>> from fractions import Fraction
>>> help(Fraction.limit_denominator)
Help on function limit_denominator in module fractions:

limit_denominator(self, max_denominator=100)
Closest Fraction to self with denominator at most max_denominator.

>>> Fraction('3.141592653589793').limit_denominator(10)
Fraction(22, 7)
>>> Fraction('3.141592653589793').limit_denominator(100)
Fraction(311, 99)
>>> Fraction(4321, 8765).limit_denominator(1)
Fraction(4321, 8765)

>>> Fraction(1/3).limit_denominator()
Fraction(1, 3)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Critic my module

[Lele Gaifax]

This thread did not mention alternative and existing modules with
(almost) the same goal, two come to mind:

* https://pypi.python.org/pypi/sh
* https://pypi.python.org/pypi/sarge

bye, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

Re: Unexpected results comparing float to Fraction

[Grant Edwards]

On 2013-07-29, MRAB  wrote:
> On 29/07/2013 17:40, Ian Kelly wrote:
>> On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico  wrote:
>>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB  wrote:
 I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
 are approximate anyway, and the float value 1/3 is more likely to be
 Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
>>>
>>> At what point should it become Fraction(1, 3)?
>>
>> At the point where the float is exactly equal to the value you get
>> from the floating-point division 1/3.  If it's some other float then
>> the user didn't get there by entering 1/3, so it's not worth trying to
>> pretend that they did.
>
> I thought that you're not meant to check for equality when using floats.

You check for equality if equality is what you want to check.  However
much of the time when people _think_ they want to check for FP
equality, they're wrong.

You'll have to consult with a spiritual advisor to determin what you
are "meant" to do...

-- 
Grant Edwards   grant.b.edwardsYow! Awright, which one of
  at   you hid my PENIS ENVY?
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [python] email 8bit encoding

[W. Trevor King]

On Sun, Jul 28, 2013 at 04:41:27PM -0700, ru...@yahoo.com wrote:
> How, using Python-3.3's email module, do I "flatten" (I think
> that's the right term) a Message object to get utf-8 encoded
> body with the headers:
>  Content-Type: text/plain; charset=UTF-8
>  Content-Transfer-Encoding: 8bit
> when the message payload was set to a python (unicode) string?

I asked about this a while back [1], but never got a response.  My
current best-guess is here [2].  My fallback flattening works for
everything except the 8-bit encoded messages using the UTF-16 charset,
but it's pretty ugly.

Let me know if you figure out something cleaner :).

Cheers,
Trevor

[1]: http://thread.gmane.org/gmane.comp.python.general/725425
[2]: https://github.com/wking/rss2email/blob/master/rss2email/email.py#L226

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Critic my module

[Devyn Collier Johnson]

On 07/29/2013 02:36 PM, Lele Gaifax wrote:

This thread did not mention alternative and existing modules with
(almost) the same goal, two come to mind:

* https://pypi.python.org/pypi/sh
* https://pypi.python.org/pypi/sarge

bye, lele.
Thanks everyone for the feedback. Clearly, I should stop my project. I 
will work on something else now (^u^)!


Mahalo,

DCJ
--
http://mail.python.org/mailman/listinfo/python-list

timing issue: shutil.rmtree and os.makedirs

[Tim]

I have the following function (Python2.7 on FreeBSD) that results in an OSError.

My intent is to pass it a directory name or path and if it exists, use 
shutil.rmtree to remove whatever is there (if it isn't a directory, try to 
unlink it); then use os.makedirs to create a new directory or path:
 
def make_clean_dir(directory):
if os.path.exists(directory):
if os.path.isdir(directory):
shutil.rmtree(directory)
else:
os.unlink(directory)
os.makedirs(directory)

The last bit of the traceback is:
File "/develop/myproject/helpers/__init__.py", line 35, in make_clean_dir
os.makedirs(directory)
  File "/usr/local/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 17] File exists: '/users/tim/testing/testing_html'

The directory 'testing_html' existed when I executed the function;
So I suppose the directory wasn't finished being removed by the time 
os.makedirs was invoked. How can avoid this? (A context manager maybe?).

thanks,
--Tim

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

Re: Unexpected results comparing float to Fraction

[Serhiy Storchaka]

29.07.13 19:09, MRAB написав(ла):

I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).


>>> def approximate_fraction(f):
prev_numer, numer = 0, 1
prev_denom, denom = 1, 0
r = f
while True:
i = math.floor(r)
prev_numer, numer = numer, i * numer + prev_numer
prev_denom, denom = denom, i * denom + prev_denom
if i == r or numer / denom == f:
break
r = 1 / (r - i)

return Fraction(numer, denom)

>>> approximate_fraction(1/3)
Fraction(1, 3)
>>> approximate_fraction(1e-17)
Fraction(1, 10)
>>> approximate_fraction(math.pi)
Fraction(245850922, 78256779)

I guess the Fraction constructor is more faster than this function.


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

Re: Unexpected results comparing float to Fraction

[Steven D'Aprano]

On Mon, 29 Jul 2013 17:20:27 +0100, Chris Angelico wrote:

 Fraction(0.3)
> Fraction(5404319552844595, 18014398509481984)
 Fraction(0.33)
> Fraction(5944751508129055, 18014398509481984)
[...]
 Fraction(0.3)
> Fraction(6004799503160661, 18014398509481984)
> 
> Rounding off like that is a job for a cool library function (one of
> which was mentioned on this list a little while ago, I believe), but not
> IMO for the Fraction constructor.

Or:

py> Fraction(1/3).limit_denominator(100)
Fraction(1, 3)


I think it would be useful for Fraction.from_float() to accept an 
optional second argument, the maximum denominator:

Fraction.from_float(x, den=None)
=> nearest fraction to float 1/3, with denominator no greater than den



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[Ian Kelly]

On Mon, Jul 29, 2013 at 12:16 PM, Rotwang  wrote:
> On 29/07/2013 17:40, Ian Kelly wrote:
>> At the point where the float is exactly equal to the value you get
>> from the floating-point division 1/3.
>
>
> But the interpreter has no way of knowing that the value 1/3 that's been
> passed to the Fraction constructor was obtained from the division 1/3,
> rather than, say, 11/30 or
> 6004799503160661/18014398509481984. How do you propose the constructor
> should decide between the many possible fractions that round to the same
> float, if not by choosing the one that evaluates to it exactly?

It should choose the fraction with the least terms that rounds to the
float.  Whether "least" here means least numerator, least denominator,
least sum of the two, or whatever is not terribly important.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: collections.Counter surprisingly slow

[Serhiy Storchaka]

29.07.13 20:19, Ian Kelly написав(ла):

On Mon, Jul 29, 2013 at 5:49 AM, Joshua Landau  wrote:

Also, couldn't Counter just extend from defaultdict?


It could, but I expect the C helper function in 3.4 will be faster
since it doesn't even need to call __missing__ in the first place.


I'm surprised, but the Counter constructor with commented out import of 
this accelerator is faster (at least for some data).



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

PEP8 79 char max

[Devyn Collier Johnson]

In Python programming, the PEP8 recommends limiting lines to a maximum 
of 79 characters because "There are still many devices around that are 
limited to 80 character lines" 
(http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices 
cannot handle 80 or more characters on a line? Would following this 
recommendation improve script performance?


Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list

import syntax

[Devyn Collier Johnson]

The PEP8 recommends importing like this:

import os
import re

not like this:

import os, re

Why is that? Is there a performance advantage to one of the styles?


Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Joel Goldstick]

On Mon, Jul 29, 2013 at 3:48 PM, Devyn Collier Johnson
 wrote:
> The PEP8 recommends importing like this:
>
> import os
> import re
>
> not like this:
>
> import os, re
>
> Why is that? Is there a performance advantage to one of the styles?
>
>
> Mahalo,
>
> Devyn Collier Johnson
> devyncjohn...@gmail.com
> --
> http://mail.python.org/mailman/listinfo/python-list

I think its just for clarity

-- 
Joel Goldstick
http://joelgoldstick.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Joel Goldstick]

On Mon, Jul 29, 2013 at 3:43 PM, Devyn Collier Johnson
 wrote:
> In Python programming, the PEP8 recommends limiting lines to a maximum of 79
> characters because "There are still many devices around that are limited to
> 80 character lines" (http://www.python.org/dev/peps/pep-0008/#code-lay-out).
> What devices cannot handle 80 or more characters on a line?

well, punch cards ;)
 Would following
> this recommendation improve script performance?

Not performance, but human readability
>
> Mahalo,
>
> Devyn Collier Johnson
> devyncjohn...@gmail.com
> --
> http://mail.python.org/mailman/listinfo/python-list



-- 
Joel Goldstick
http://joelgoldstick.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Dave Angel]

On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:

The PEP8 recommends importing like this:

import os
import re

not like this:

import os, re

Why is that? Is there a performance advantage to one of the styles?




Pep 8 is not about performance, it's about readability.  And unless the 
two libraries are closely related, it's clearer to use separate lines 
for them.


I got a bit further, and if I'm only using a couple of functions from 
the import, I'll list them in the comment.


--
DaveA

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

Re: import syntax

[Tim Chase]

On 2013-07-29 15:48, Devyn Collier Johnson wrote:
> The PEP8 recommends importing like this:
> 
> import os
> import re
> 
> not like this:
> 
> import os, re
> 
> Why is that? Is there a performance advantage to one of the styles?

While I don't believe there's much of a performance difference (if
so, it should be pretty negligible, especially since imports are
usually just done at load-time rather than run-time), but

1) it's easier to read one-per-line (IMHO), particularly if you sort
them alphabetically

2) it makes for cleaner diffs

Which would you rather read and try to figure out what's going on?

  =
  --- before.py   2013-07-29 15:04:38.250996094 -0500
  +++ after.py2013-07-29 15:04:44.026996132 -0500
  @@ -1 +1 @@
  -import csv, re, sys, os
  +import csv, re, sys, glob, os
  =

vs.

  =
  --- before.py   2013-07-29 15:13:13.050997907 -0500
  +++ after.py2013-07-29 15:13:18.434997950 -0500
  @@ -1,4 +1,5 @@
   import csv
  +import glob
   import os
   import re
   import sys
  =

The latter makes it much easier (at least for me) to spot that "glob"
was added.  And it's more tolerant of merge-conflict resolution.

-tkc




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

Re: import syntax

[Tim Chase]

On 2013-07-29 16:09, Dave Angel wrote:
> On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:
> > The PEP8 recommends importing like this:
> >
> > import os
> > import re
> >
> > not like this:
> >
> > import os, re
>
> I got a bit further, and if I'm only using a couple of functions
> from the import, I'll list them in the comment.

If I just plan to use a small subset, I tend to reach for the

  from sys import stdout, stderr, exit

sort of syntax.  I find it makes my code read a bit more cleanly than
having to type "sys.stderr.write(...)" everywhere but is still pretty
readable.

-tkc


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

Re: Unexpected results comparing float to Fraction

[Steven D'Aprano]

On Mon, 29 Jul 2013 18:04:19 +0100, MRAB wrote:

> I thought that you're not meant to check for equality when using floats.

Heavens no. You're only meant to *mostly* not check for equality using 
floats. As Miracle Max might say:

"It just so happens that floats are only MOSTLY inexact. There's a big 
difference between mostly inexact and all inexact. Mostly inexact is 
slightly exact."


Or to be a little more serious, "never check floats for equality" is 
actually pretty lousy advice. As Professor William Kahan puts it, the 
word "never" makes it rank superstition. 

There are three main problems with the general advice "never check floats 
for equality":

1) there are perfectly fine situations where you can check floats 
   for (in)equality without any problem, e.g.:

   if x == 0.0: print "Division by zero"
   else: y = 1/x  # perfectly safe

2) most of the time, those giving this advice don't actually say 
   what you should do instead;

3) and when they do, it's often either flat-out wrong, or at least
   incomplete.


For example, you might have been told to instead check whether your float 
is less than some epsilon:

abs(x - y) < eps

But chances are you've never been given any sort of reliable, 
deterministic algorithm for deciding what value eps should have. (Mostly 
because there is no such algorithm!) Or for deciding when to use absolute 
differences, like the above, and when to use relative differences.

Another issue: if eps is too big, you're taking distinct values and 
treating them as the same, which is bad. And if eps is too small, you're 
actually doing what you said you should never do, only slower.

E.g. suppose you want to check for a float which equals some value M, 
I'll pick M = 219902322.0 semi-arbitrarily, but it could be any of 
many numbers. You don't want to use equality, so you pick an epsilon:

eps = 1e-6  # seems reasonable...

and then test values like this:

M = 219902322.0
if abs(x - M) <= eps:
print("close enough")


That is just a longer and slower way of calculating x == M. Why? Because 
the two floats immediately adjacent to M differ by more than your epsilon:

py> M = 219902322.0
py> M.hex()
'0x1.0p+41'
py> float.fromhex('0x1.1p+41') - M
0.00048828125
py> M - float.fromhex('0x1.fp+40')
0.000244140625

So in this case, any epsilon below 0.000244140625 is just wasting your 
time, since it cannot possibly detect any value other than M itself. And 
that critical cut-off depends on the numbers you are calculating with.

Oh, for what it's worth, I don't pretend to know how to choose an epsilon 
either. I can sometimes recognise a bad epsilon, but not a good one. 
Floats are *hard*.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Devyn Collier Johnson]

On 07/29/2013 04:20 PM, Tim Chase wrote:

On 2013-07-29 16:09, Dave Angel wrote:

On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:

The PEP8 recommends importing like this:

import os
import re

not like this:

import os, re

I got a bit further, and if I'm only using a couple of functions
from the import, I'll list them in the comment.

If I just plan to use a small subset, I tend to reach for the

   from sys import stdout, stderr, exit

sort of syntax.  I find it makes my code read a bit more cleanly than
having to type "sys.stderr.write(...)" everywhere but is still pretty
readable.

-tkc



So, there are no advantages or disadvantages when disregarding readability?

DCJ
--
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Devyn Collier Johnson]

On 07/29/2013 04:08 PM, Joel Goldstick wrote:

On Mon, Jul 29, 2013 at 3:43 PM, Devyn Collier Johnson
 wrote:

In Python programming, the PEP8 recommends limiting lines to a maximum of 79
characters because "There are still many devices around that are limited to
80 character lines" (http://www.python.org/dev/peps/pep-0008/#code-lay-out).
What devices cannot handle 80 or more characters on a line?

well, punch cards ;)
  Would following

this recommendation improve script performance?

Not performance, but human readability

Mahalo,

Devyn Collier Johnson
devyncjohn...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list



So, I can have a script with large lines and not negatively influence 
performance on systems that do not use punch cards?


DCJ
--
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Ed Leafe]

On Jul 29, 2013, at 3:08 PM, Joel Goldstick  wrote:

>> Would following
>> this recommendation improve script performance?
> 
> Not performance, but human readability

IMO, this isn't always the case. There are many lines of code that are 
broken up to meet the 79 character limit, and as a result become much less 
readable. 


-- Ed Leafe





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

Re: PEP8 79 char max

[John Gordon]

In  Devyn Collier Johnson 
 writes:

> (http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices 
> cannot handle 80 or more characters on a line?

For a start, older fixed-width dumb terminals and printers.  And even some
very new devices (tablet, smartphone) might have limited screen sizes.

And even if you're on a device that can display more than 80 characters, it
can be convenient to have several windows display side-to-side.

> Would following this recommendation improve script performance?

No, but it improves human readability.

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: Unexpected results comparing float to Fraction

[Ian Kelly]

On Jul 29, 2013 1:37 PM, "Serhiy Storchaka"  wrote:
>
> 29.07.13 19:09, MRAB написав(ла):
>
>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>> are approximate anyway, and the float value 1/3 is more likely to be
>> Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
>
>
> >>> def approximate_fraction(f):
> prev_numer, numer = 0, 1
> prev_denom, denom = 1, 0
> r = f
> while True:
> i = math.floor(r)
> prev_numer, numer = numer, i * numer + prev_numer
> prev_denom, denom = denom, i * denom + prev_denom
> if i == r or numer / denom == f:
> break
> r = 1 / (r - i)
>
> return Fraction(numer, denom)
>
> >>> approximate_fraction(1/3)
> Fraction(1, 3)
> >>> approximate_fraction(1e-17)
> Fraction(1, 10)
> >>> approximate_fraction(math.pi)
> Fraction(245850922, 78256779)
>
> I guess the Fraction constructor is more faster than this function.

You might be able to speed it up a bit with numpy and the observation that
the update is a matrix multiplication. But I don't think that you can get
away from it being an iterative algorithm.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unexpected results comparing float to Fraction

[Terry Reedy]

On 7/29/2013 1:29 PM, Steven D'Aprano wrote:

On Mon, 29 Jul 2013 13:08:20 -0400, Terry Reedy wrote:


In other words, there can be multiple unequal Franctions that have the
same float value: for instance, Fraction(1,3) and
Fraction(6004799503160661, 18014398509481984)

  > So from that standpoint it makes sense to me to cast to Fraction when
  > comparing.

Otherwise, == becomes non-transitive


This is Python, and we can make __eq__ methods that do anything,
including be non-transitive, non-reflexive, and nonsensical if we like :-)


Yes, Python's developers can intentionally introduce bugs, but we try 
not to. The definitions of sets and dicts and containment assume that == 
means equality as mathematically defined. As one time, we had 0 == 0.0 
and 0 == Decimal(0) but 0.0 != Decimal(0) (and so on for all integral 
float values. That 'misfeature' was corrected because of the 'problems' 
it caused. That lesson learned, one of the design requirements for the 
new enum class (metaclass) was that it not re-introduce non-transitivity.


--
Terry Jan Reedy

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

Has anyone gotten Pyglet to work

[Devyn Collier Johnson]

I tried Pyglet in a Python3 and a Python2 script, but both fail. The 
error code is below and the script is attached. The 'boot.ogg' file is 
Ubuntu's default bootup sound. I got my code from this link 
(http://guzalexander.com/2012/08/17/playing-a-sound-with-python.html).


collier@Nacho-Laptop:~$ ./pyglet.py
Traceback (most recent call last):
  File "./pyglet.py", line 2, in 
import pyglet
  File "/home/collier/pyglet.py", line 3, in 
song = pyglet.media.load('./boot.ogg')
AttributeError: 'module' object has no attribute 'media'


Mahalo,

DCJ
#!/usr/bin/env python
import pyglet
song = pyglet.media.load('./boot.ogg')
song.play()
pyglet.app.run()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Terry Reedy]

On 7/29/2013 3:43 PM, Devyn Collier Johnson wrote:

In Python programming, the PEP8 recommends limiting lines to a maximum
of 79 characters because "There are still many devices around that are
limited to 80 character lines"


"plus, limiting windows to 80 characters makes it possible to have 
several windows side-by-side. "



(http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices
cannot handle 80 or more characters on a line?


PEP 8 is being revised. My understanding is that because such machines 
are now rare, while the second reason is still operative, the 
recommended limit will be raised to 100, or at least say that some are 
using that as the guideline. 200 char lines are harder to read.


--
Terry Jan Reedy

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

Re: PEP8 79 char max

[Steven D'Aprano]

On Mon, 29 Jul 2013 15:43:49 -0400, Devyn Collier Johnson wrote:

> In Python programming, the PEP8 recommends limiting lines to a maximum
> of 79 characters because "There are still many devices around that are
> limited to 80 character lines"
> (http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices
> cannot handle 80 or more characters on a line? 

The only one I can think of is actual xterms (Ctrl-Alt-Function key 
terminals on Unix and Linux). But I think that's actually a red-herring. 
At least for me, I don't care about devices with 80 character lines. 
(Smart phones? Or is that more likely to be 40 character lines?)

I care about being able to put multiple windows side-by-side, or a single 
window with code in one pane and a class map at the side. I care about 
being able to copy and paste code into an email, or Usenet post, without 
it being mangled. I care about *never* having to scroll left-to-right in 
order to read a line.

And most of all, I care about lines being short enough to read without 
eye strain and mental fatigue from excessive horizontal width.


> Would following this
> recommendation improve script performance?

No, it is irrelevant to performance, except performance of the reader.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Has anyone gotten Pyglet to work

[Gary Herron]

On 07/29/2013 01:56 PM, Devyn Collier Johnson wrote:
I tried Pyglet in a Python3 and a Python2 script, but both fail. The 
error code is below and the script is attached. The 'boot.ogg' file is 
Ubuntu's default bootup sound. I got my code from this link 
(http://guzalexander.com/2012/08/17/playing-a-sound-with-python.html).


collier@Nacho-Laptop:~$ ./pyglet.py
Traceback (most recent call last):
  File "./pyglet.py", line 2, in 
import pyglet
  File "/home/collier/pyglet.py", line 3, in 
song = pyglet.media.load('./boot.ogg')
AttributeError: 'module' object has no attribute 'media'


Mahalo,

DCJ




You appear to have confused Python by having a module named pyglet AND a 
local file named pyglet.py.


This when you say import pyglet, you are not getting the pyglet module, 
but instead your own file pyglet.py, which of course, has nothing named 
media in it.


Rename your file and try again.

P.S.  It is a common newbie error to hide a system file like this and 
suffer the consequence.  We've all done it -- at least once. :^) )


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

Re: Critic my module

[Joshua Landau]

On 29 July 2013 19:36, Lele Gaifax  wrote:

> This thread did not mention alternative and existing modules with
> (almost) the same goal, two come to mind:
>
> * https://pypi.python.org/pypi/sh
> * https://pypi.python.org/pypi/sarge


Actually, I noted both those and plumbum.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Skip Montanaro]

For the purposes of limiting the length you need to scan between first
and last column, I would recommend leaving the recommended line length
to ~ 80 columns.

Just for grins, I grabbed a non-computer book, Atul Gawande's
"Checklist Manifesto," from the pile on my desk and counted the number
of characters in a full-width line.  70.  Then I grabbed my copy of
"Mastering Regular Expressions" and counted the number of characters
in a full-width line of text which also included a few special
characters.  80.

I think the history of printing offers a good gauge for the useful
limits to line length.  After all, print publishers have been at this
for more than a few years.

As I typed this, Steven D'Aprano wrote:

> No, it is irrelevant to performance, except performance of the reader.

Whose performance, I would argue is most important.

I would like to hear of books meant to be read with page or column
widths of 100 or more characters.  I suspect they would be few and far
between.

Skip
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Steven D'Aprano]

On Mon, 29 Jul 2013 15:18:59 -0500, Ed Leafe wrote:

> On Jul 29, 2013, at 3:08 PM, Joel Goldstick 
> wrote:
>> Not performance, but human readability
> 
>   IMO, this isn't always the case. There are many lines of code 
that are
>   broken up to meet the 79 character limit, and as a result become 
much
>   less readable.

Speaking of readability, what's with the indentation of your post? The 
leading tab plays havoc with my newsreader's word-wrapping.

Breaking lines to fit in 79 characters should almost always be perfectly 
readable, if you break it at natural code units rather than at random 
places. E.g. I have a code snippet that looks like this:

[whatever...]
else:
completer = completer.Completer(
bindings=(r'"\C-xo": overwrite-mode',
  r'"\C-xd": dump-functions',
  )
)

I'm not entirely happy with the placement of the closing brackets, but by 
breaking the line at the arguments to Completer, and then putting one 
binding per line, I think it is perfectly readable. And much more 
readable than (say) this:


else:
completer = completer.Completer(bindings=
(r'"\C-xo": overwrite-mode', r'"\C-xd": dump-functions',))


As far as I can tell, that's pretty much the longest line I have in my 
personal code base, possibly excepting unit tests with long lists of 
data. I simply don't write deeply nested classes and functions unless I 
absolutely need to.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Has anyone gotten Pyglet to work

[Lee Harr]

> $ ./pyglet.py
> Traceback (most recent call last):
>    File "./pyglet.py", line 2, in 
>      import pyglet
>    File "/home/collier/pyglet.py", line 3, in 
>      song = pyglet.media.load('./boot.ogg')
> AttributeError: 'module' object has no attribute 'media'


Name your program something other than "pyglet.py"

import pyglet

is importing your module, instead of the pyglet module. 
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to package embedded python?

[Kevin Walzer]

On 7/25/13 5:05 PM, David M. Cotter wrote:

what must i include in my app package if i'm embedding python?

i tried including *everything* in the "DLLs" directory, but my app still 
crashes as soon as i attempt to initialize python.

this is on a system that does not have python installed, as most of my users 
won't have it.  is it actually a requirement that they first install python?  
(cuz it does work then)



Have you looked at these docs?

http://docs.python.org/2/extending/embedding.html

Lots of other hits on Google for ""embedding Python in C app."

--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Has anyone gotten Pyglet to work

[Steven D'Aprano]

On Mon, 29 Jul 2013 16:56:06 -0400, Devyn Collier Johnson wrote:

> collier@Nacho-Laptop:~$ ./pyglet.py

Here you are running a module called pyglet, which I assume you wrote.


> Traceback (most recent call last):
>File "./pyglet.py", line 2, in 
>  import pyglet

And here you try to import the third-party module called pyglet, except 
it is shadowed by your module, and you get your own module instead.

>File "/home/collier/pyglet.py", line 3, in 
>  song = pyglet.media.load('./boot.ogg')
> AttributeError: 'module' object has no attribute 'media'

Since your module has no attribute 'media', that error is correct.



The lesson here is, never name your own files the same as library files. 
Unfortunately, that's easier said than done. I think everyone has made 
the same mistake at least once in their life as a Python programmer.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Steven D'Aprano]

On Mon, 29 Jul 2013 16:24:51 -0400, Devyn Collier Johnson wrote:

> So, I can have a script with large lines and not negatively influence
> performance on systems that do not use punch cards?

You'll negatively influence anyone who has to read, or edit, your code. 
Very likely including you.

But no, there's no meaningful performance difference based on line 
length. Interpreting the source code is not meaningfully affected by line 
length, and by the time the code is compiled and then run, line length is 
irrelevant.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bitwise Operations

[Grant Edwards]

On 2013-07-29, Devyn Collier Johnson  wrote:

> On Python3, how can I perform bitwise operations? For instance, I want 
> something that will 'and', 'or', and 'xor' a binary integer.

http://www.google.com/search?q=python+bitwise+operations

-- 
Grant Edwards   grant.b.edwardsYow! I have the power to
  at   HALT PRODUCTION on all
  gmail.comTEENAGE SEX COMEDIES!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Bitwise Operations

[Devyn Collier Johnson]

On Python3, how can I perform bitwise operations? For instance, I want 
something that will 'and', 'or', and 'xor' a binary integer.


Mahalo,

devyncjohn...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Terry Reedy]

On 7/29/2013 5:01 PM, Terry Reedy wrote:

On 7/29/2013 3:43 PM, Devyn Collier Johnson wrote:

In Python programming, the PEP8 recommends limiting lines to a maximum
of 79 characters because "There are still many devices around that are
limited to 80 character lines"


"plus, limiting windows to 80 characters makes it possible to have
several windows side-by-side. "


(http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices
cannot handle 80 or more characters on a line?


PEP 8 is being revised. My understanding is that because such machines
are now rare, while the second reason is still operative, the
recommended limit will be raised to 100,


or maybe not, as there is disagreement on the issue also ;-).

 or at least say that some are

using that as the guideline. 200 char lines are harder to read.




--
Terry Jan Reedy

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

Pyglet on Python3.x, problems

[John Ladasky]

Hi folks,

For whatever reason, the pyglet package is getting a lot of attention on 
c.l.python these past few days.  I am guilty of generating some of that 
potentially off-topic conversation myself.  At the end of my last thread, I 
reported that I had found the pyglet-users newsgroup, and would direct my 
questions there.

https://groups.google.com/d/msg/comp.lang.python/ARtI0GC9RHc/_6URRrhz7nUJ

Well, I joined pyglet-users.  I have waited for about 36 hours for the 
moderator to approve my first post asking for help.  Several other posts have 
appeared, but not mine.  I don't think that I was impolite.

Apologies to everyone, but I'm going to ask my questions here.  As you may 
recall, I'm teaching some adolescent computer programming students.  I need a 
Python 3-compatible GUI, preferably one oriented towards games.  I might have 
that GUI in hand, but I need to test it myself first.  I've been researching 
this issue for over a week.  I have a student tomorrow, so I'm facing a bit of 
a deadline.  (Yeah, I could teach him about B-trees instead, but... you know, 
kids.)

In my own defense, I'm not entirely certain that the problems I have 
encountered are specific to pyglet.  They might have to do with the limitations 
of the 2to3 program.

I'm starting with my own Ubuntu 13.04 system.  I downloaded pyglet-1.2alpha1, 
unzipped it and executed "sudo python3 setup.py install", as I have done with 
many a package.  Then I tried running various programs in two directories 
(these programs are also on the pyglet.org web site).

pyglet-1.2alpha1/examples/programming_guide/hello_world.py runs fine.

pyglet-1.2alpha1/examples/programming_guide/image_viewer.py also runs fine.

pyglet-1.2alpha1/examples/programming_guide/animation.py produces an error.  
Here's the traceback.

===

Traceback (most recent call last):
  File "/usr/local/lib/python3.3/dist-packages/pyglet/resource.py", line 538, 
in animation
identity = self._cached_animations[name]
  File "/usr/lib/python3.3/weakref.py", line 69, in __getitem__
o = self.data[key]()
KeyError: 'dinosaur.gif'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "animation.py", line 62, in 
animation = pyglet.resource.animation('dinosaur.gif')
  File "/usr/local/lib/python3.3/dist-packages/pyglet/resource.py", line 540, 
in animation
animation = pyglet.image.load_animation(name, self.file(name))
  File "/usr/local/lib/python3.3/dist-packages/pyglet/image/__init__.py", line 
2425, in load_animation
raise first_exception  
  File "/usr/local/lib/python3.3/dist-packages/pyglet/image/__init__.py", line 
2417, in load_animation
image = decoder.decode_animation(file, filename)
  File 
"/usr/local/lib/python3.3/dist-packages/pyglet/image/codecs/gdkpixbuf2.py", 
line 121, in decode_animation
gif_stream = gif.read(file)
  File "/usr/local/lib/python3.3/dist-packages/pyglet/image/codecs/gif.py", 
line 85, in read
raise ImageDecodeException('Not a GIF stream')
pyglet.image.codecs.ImageDecodeException: Not a GIF stream

===

>From earlier discussions, I know that distutils automatically executes 2to3 on 
>the pyglet core module, when you invoke pyglet's setup.py file from Python 3.  
>The setup script does not appear to run 2to3 on the code outside of the 
>package itself.  And while I doubted that the KeyError I saw above was a 
>Python 2/3 compatibility issue, I tried running 2to3 on animation.py anyway.  
>2to3 seems to agree with me, reporting back "RefactoringTool: No files need to 
>be modified."

Finally, I got errors when trying to run pyglet-1.2alpha1/tests/test.py.  At 
first, it looked like the fix would be easy:

===

File "tests/test.py", line 274
  print '-' * 78
  ^
SyntaxError: invalid syntax

===

Clearly this was a problem for 2to3, so I ran it on test.py.  It corrected that 
one print statement, and nothing else.  Then I ran test.py again.  This time I 
got a deeper problem:

===

Traceback (most recent call last):
  File "test.py", line 215, in 
import tests.regression
  File "../tests/regression/__init__.py", line 11, in 
from pyglet.image import get_buffer_manager
  File "../pyglet/__init__.py", line 276
print '[%d] %s%s %s' % (thread, indent, name, location)
   ^
SyntaxError: invalid syntax

===

This error suggests that, during the build and install process, 2to3 left some 
code uncorrected in pyglet/__init__.py.  This has me worried.  Could there be 
other code that 2to3 failed to correct?  I don't want to offer my students a 
tool, only to have it crash on them.

So, there you have it, the two errors that I am encount

Re: PEP8 79 char max

[Joshua Landau]

On 29 July 2013 22:18, Skip Montanaro  wrote:

> For the purposes of limiting the length you need to scan between first
> and last column, I would recommend leaving the recommended line length
> to ~ 80 columns.
>
> Just for grins, I grabbed a non-computer book, Atul Gawande's
> "Checklist Manifesto," from the pile on my desk and counted the number
> of characters in a full-width line.  70.  Then I grabbed my copy of
> "Mastering Regular Expressions" and counted the number of characters
> in a full-width line of text which also included a few special
> characters.  80.
>
> I think the history of printing offers a good gauge for the useful
> limits to line length.  After all, print publishers have been at this
> for more than a few years.
>
> As I typed this, Steven D'Aprano wrote:
>
> > No, it is irrelevant to performance, except performance of the reader.
>
> Whose performance, I would argue is most important.
>
> I would like to hear of books meant to be read with page or column
> widths of 100 or more characters.  I suspect they would be few and far
> between.
>

In that gauge I would exclude indentation (you don't count the number of
characters the margin takes) and would point out that programming doesn't
have generically-wrapped lines -- sometimes the wrapping of a line is more
distracting than its length. Written text has a completely different flow
to programs; written text is read sequentially where missing the reading of
words is a trivial and oft occurrence whereas programming is highly
structured.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Has anyone gotten Pyglet to work

[Devyn Collier Johnson]

On 07/29/2013 05:08 PM, Gary Herron wrote:

On 07/29/2013 01:56 PM, Devyn Collier Johnson wrote:
I tried Pyglet in a Python3 and a Python2 script, but both fail. The 
error code is below and the script is attached. The 'boot.ogg' file 
is Ubuntu's default bootup sound. I got my code from this link 
(http://guzalexander.com/2012/08/17/playing-a-sound-with-python.html).


collier@Nacho-Laptop:~$ ./pyglet.py
Traceback (most recent call last):
  File "./pyglet.py", line 2, in 
import pyglet
  File "/home/collier/pyglet.py", line 3, in 
song = pyglet.media.load('./boot.ogg')
AttributeError: 'module' object has no attribute 'media'


Mahalo,

DCJ




You appear to have confused Python by having a module named pyglet AND 
a local file named pyglet.py.


This when you say import pyglet, you are not getting the pyglet 
module, but instead your own file pyglet.py, which of course, has 
nothing named media in it.


Rename your file and try again.

P.S.  It is a common newbie error to hide a system file like this and 
suffer the consequence.  We've all done it -- at least once. :^) )




Duh, thanks for the tip (^u^), but I still get an error (different 
error). NOTE: this is all python2.7 code because Pyglet supposedly has 
issues with Python3.


collier@Nacho-Laptop:~$ pip install pyglet
Downloading/unpacking pyglet
  Downloading pyglet-1.1.4.tar.gz (2.9MB): 2.9MB downloaded
  Running setup.py egg_info for package pyglet
...Blah
...Blah
Installing collected packages: pyglet
  Running setup.py install for pyglet
Successfully installed pyglet
Cleaning up...
collier@Nacho-Laptop:~/pytest$ ./pymedia.py
Traceback (most recent call last):
  File "./pymedia.py", line 3, in 
song = pyglet.media.load('./boot.ogg')
  File 
"/usr/local/lib/python2.7/dist-packages/pyglet/media/__init__.py", line 
1386, in load

source = _source_class(filename, file)
  File "/usr/local/lib/python2.7/dist-packages/pyglet/media/riff.py", 
line 202, in __init__

'AVbin is required to decode compressed media')
pyglet.media.riff.WAVEFormatException: AVbin is required to decode 
compressed media

AL lib: ReleaseALC: 1 device not closed
collier@Nacho-Laptop:~/pytest$ ls
boot.ogg  pymedia.py



Mahalo,

DCJ
#!/usr/bin/env python
import pyglet
song = pyglet.media.load('./boot.ogg')
song.play()
pyglet.app.run()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Devyn Collier Johnson]

On 07/29/2013 05:42 PM, Steven D'Aprano wrote:

On Mon, 29 Jul 2013 16:24:51 -0400, Devyn Collier Johnson wrote:


So, I can have a script with large lines and not negatively influence
performance on systems that do not use punch cards?

You'll negatively influence anyone who has to read, or edit, your code.
Very likely including you.

But no, there's no meaningful performance difference based on line
length. Interpreting the source code is not meaningfully affected by line
length, and by the time the code is compiled and then run, line length is
irrelevant.



Evidently, it is personal preference. I prefer to read computer code 
like a book (yes, I am a weirdo (^u^)). The only time I exced 79 
characters is when I write a set of commands that perform similar tasks. 
I do not make too many lines over 79 char. Thanks everyone for the 
comments and feedback.


Mahalo,

DCJ
--
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Joshua Landau]

On 29 July 2013 22:34, Steven D'Aprano  wrote:

> On Mon, 29 Jul 2013 15:18:59 -0500, Ed Leafe wrote:
>
> > On Jul 29, 2013, at 3:08 PM, Joel Goldstick 
> > wrote:
> >> Not performance, but human readability
> >
> >   IMO, this isn't always the case. There are many lines of code
> that are
> >   broken up to meet the 79 character limit, and as a result become
> much
> >   less readable.
>
> Speaking of readability, what's with the indentation of your post? The
> leading tab plays havoc with my newsreader's word-wrapping.
>
> Breaking lines to fit in 79 characters should almost always be perfectly
> readable, if you break it at natural code units rather than at random
> places. E.g. I have a code snippet that looks like this:
>
> [whatever...]
> else:
> completer = completer.Completer(
> bindings=(r'"\C-xo": overwrite-mode',
>   r'"\C-xd": dump-functions',
>   )
> )
>
> I'm not entirely happy with the placement of the closing brackets, but by
> breaking the line at the arguments to Completer, and then putting one
> binding per line, I think it is perfectly readable. And much more
> readable than (say) this:
>
>
> else:
> completer = completer.Completer(bindings=
> (r'"\C-xo": overwrite-mode', r'"\C-xd": dump-functions',))
>

But less readable to me than:

completer = completer.Completer(bindings=[r'"\C-xo": overwrite-mode',
r'"\C-xd": dump-functions'])

Personal preference.

As far as I can tell, that's pretty much the longest line I have in my
> personal code base, possibly excepting unit tests with long lists of
> data. I simply don't write deeply nested classes and functions unless I
> absolutely need to.


I'd go for:

completer = completer.Completer(bindings=[
  r'"\C-xo": overwrite-mode',
  r'"\C-xd": dump-functions'
])

although possibly drop the "bindings=" if possible. "[]" is less ambiguous
a construct than "()"¹ and the "balance" of the code is better my way if
such ephemeral ideas as that count.

Anyway, the point I'm trying to make is that *line length is a personal
thing*. There are two rules:

1) Stick with what other people on the team are doing, if relevant
2) Don't be stupid

The rest is your choice. Some people like 80 character limits, but I've
consistently preferred "whatever you think" as a better rule.

¹ As in there are fewer possible uses, so it's quicker to know what you're
using it for
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import syntax

[Joshua Landau]

On 29 July 2013 21:23, Devyn Collier Johnson wrote:

>
> On 07/29/2013 04:20 PM, Tim Chase wrote:
>
>> On 2013-07-29 16:09, Dave Angel wrote:
>>
>>> On 07/29/2013 03:48 PM, Devyn Collier Johnson wrote:
>>>
 The PEP8 recommends importing like this:

 import os
 import re

 not like this:

 import os, re

>>> I got a bit further, and if I'm only using a couple of functions
>>> from the import, I'll list them in the comment.
>>>
>> If I just plan to use a small subset, I tend to reach for the
>>
>>from sys import stdout, stderr, exit
>>
>> sort of syntax.  I find it makes my code read a bit more cleanly than
>> having to type "sys.stderr.write(...)" everywhere but is still pretty
>> readable.
>>
>> -tkc
>>
>>
>>  So, there are no advantages or disadvantages when disregarding
> readability?


Sure, just as one light is no brighter or dimmer than another when
disregarding luminosity.

As people have said, it improves diffs as well. It flows quicker into the
"from module import things" form (which I oft prefer), too.

When asking these questions, ask yourself "why would it *compile*
differently? It wouldn't. Plus, premature optimisation is the root of all
evil.

1) Write your code
2) If it's slow:
2a) Do you have time? If so:
2b) Is it important to speed up, or is the slowness not worth spending the
hours fixing?
2c) Profile it to see what's actually slow
2d) Realise that the slow part is not what you thought it was
2e) Fix the bit that's slow (and nothing else)
2f) Repeat from 2
3) Write some more code
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Has anyone gotten Pyglet to work

[Steven D'Aprano]

On Mon, 29 Jul 2013 18:22:02 -0400, Devyn Collier Johnson wrote:

> Duh, thanks for the tip (^u^), but I still get an error (different
> error). NOTE: this is all python2.7 code because Pyglet supposedly has
> issues with Python3.
[...]
> Traceback (most recent call last):
>File "./pymedia.py", line 3, in 
>  song = pyglet.media.load('./boot.ogg')
>File
> "/usr/local/lib/python2.7/dist-packages/pyglet/media/__init__.py", line
> 1386, in load
>  source = _source_class(filename, file)
>File "/usr/local/lib/python2.7/dist-packages/pyglet/media/riff.py",
> line 202, in __init__
>  'AVbin is required to decode compressed media')
> pyglet.media.riff.WAVEFormatException: AVbin is required to decode
> compressed media


You have a media file (boot.ogg) which pyglet is trying to play using 
AVbin, but you don't have AVbin.

As far as I know, pip is incapable of handling non-Python dependencies. I 
suggest you try your system's package manager:

Debian/Ubuntu:

sudo aptitude install AVbin

-or- 

sudo apt-get install AVbin



RedHat/Fedora/Centos:

sudo yum install AVbin


and hopefully your distro will already support the latest, or at least 
working, version.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Has anyone gotten Pyglet to work

[Joshua Landau]

On 29 July 2013 23:22, Devyn Collier Johnson wrote:

> Duh, thanks for the tip (^u^), but I still get an error (different error).
> NOTE: this is all python2.7 code because Pyglet supposedly has issues with
> Python3.
>
> collier@Nacho-Laptop:~$ pip install pyglet
> Downloading/unpacking pyglet
>   Downloading pyglet-1.1.4.tar.gz (2.9MB): 2.9MB downloaded
>   Running setup.py egg_info for package pyglet
> ...Blah
> ...Blah
> Installing collected packages: pyglet
>   Running setup.py install for pyglet
> Successfully installed pyglet
> Cleaning up...
> collier@Nacho-Laptop:~/pytest$ ./pymedia.py
>
> Traceback (most recent call last):
>   File "./pymedia.py", line 3, in 
>
> song = pyglet.media.load('./boot.ogg')
>   File "/usr/local/lib/python2.7/dist-packages/pyglet/media/__init__.py",
> line 1386, in load
> source = _source_class(filename, file)
>   File "/usr/local/lib/python2.7/dist-packages/pyglet/media/riff.py", line
> 202, in __init__
> 'AVbin is required to decode compressed media')
> pyglet.media.riff.WAVEFormatException: AVbin is required to decode
> compressed media
> AL lib: ReleaseALC: 1 device not closed
> collier@Nacho-Laptop:~/pytest$ ls
> boot.ogg  pymedia.py
>

This line:

> pyglet.media.riff.WAVEFormatException: AVbin is required to decode
compressed media

You should read your exceptions very carefully, they're normally there for
a very good reason.

Then Google that line. Then get
http://stackoverflow.com/questions/10302873/python-pyglet-avbin-how-to-install-avbin
(first
link for me). As someone who knows nothing about this, that's your best
bet. If not, Google's other links looked promising.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP8 79 char max

[Ed Leafe]

On Jul 29, 2013, at 5:30 PM, Devyn Collier Johnson  
wrote:

> Evidently, it is personal preference. I prefer to read computer code like a 
> book (yes, I am a weirdo (^u^)). The only time I exced 79 characters is when 
> I write a set of commands that perform similar tasks. I do not make too many 
> lines over 79 char. Thanks everyone for the comments and feedback.

I have heard this statement before, and so I'm wondering: do you read books 
printed in monospaced typefaces, or do they have proportional fonts? I've yet 
to come across anything meant to be read as literature that was monospaced, 
because it is much harder to read.

I had read about a developer who switched to using proportional fonts for 
coding, and somewhat skeptically, tried it out. After a day or so it stopped 
looking strange, and after a week it seemed so much easier to read. I only 
switched back because I found I lost productivity switching from vim to a 
graphical text editor.


-- Ed Leafe





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

Re: PEP8 79 char max

[Rhodri James]

On Mon, 29 Jul 2013 22:09:10 +0100, Steven D'Aprano  
 wrote:



On Mon, 29 Jul 2013 15:43:49 -0400, Devyn Collier Johnson wrote:


In Python programming, the PEP8 recommends limiting lines to a maximum
of 79 characters because "There are still many devices around that are
limited to 80 character lines"
(http://www.python.org/dev/peps/pep-0008/#code-lay-out). What devices
cannot handle 80 or more characters on a line?


The only one I can think of is actual xterms (Ctrl-Alt-Function key
terminals on Unix and Linux). But I think that's actually a red-herring.
At least for me, I don't care about devices with 80 character lines.
(Smart phones? Or is that more likely to be 40 character lines?)

I care about being able to put multiple windows side-by-side, or a single
window with code in one pane and a class map at the side. I care about
being able to copy and paste code into an email, or Usenet post, without
it being mangled. I care about *never* having to scroll left-to-right in
order to read a line.

And most of all, I care about lines being short enough to read without
eye strain and mental fatigue from excessive horizontal width.


+1

I'm working on some shonky C code at the moment that inconsistent  
indentation and very long lines.  It is extremely annoying not to be able  
to put the original code, my "translation" and sundry utilities all  
side-by-side on the same screen (and it's not a particularly small  
screen), and having to keep flipping between them slows me down  
dramatically.  Long lines have no effect on the speed of the program, but  
they can have serious effects on the speed of the programmer.


--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: Pyglet on Python3.x, problems

[Joshua Landau]

On 29 July 2013 23:04, John Ladasky  wrote:

> For whatever reason, the pyglet package is getting a lot of attention on
> c.l.python these past few days.  I am guilty of generating some of that
> potentially off-topic conversation myself.  At the end of my last thread, I
> reported that I had found the pyglet-users newsgroup, and would direct my
> questions there.
>
> https://groups.google.com/d/msg/comp.lang.python/ARtI0GC9RHc/_6URRrhz7nUJ


I suggest you redirect to the archives from
http://mail.python.org/pipermail/python-list/.


> Well, I joined pyglet-users.  I have waited for about 36 hours for the
> moderator to approve my first post asking for help.  Several other posts
> have appeared, but not mine.  I don't think that I was impolite.
>
> Apologies to everyone, but I'm going to ask my questions here.  As you may
> recall, I'm teaching some adolescent computer programming students.  I need
> a Python 3-compatible GUI, preferably one oriented towards games.  I might
> have that GUI in hand, but I need to test it myself first.  I've been
> researching this issue for over a week.  I have a student tomorrow, so I'm
> facing a bit of a deadline.  (Yeah, I could teach him about B-trees
> instead, but... you know, kids.)
>
> In my own defense, I'm not entirely certain that the problems I have
> encountered are specific to pyglet.  They might have to do with the
> limitations of the 2to3 program.
>
> I'm starting with my own Ubuntu 13.04 system.  I downloaded
> pyglet-1.2alpha1, unzipped it and executed "sudo python3 setup.py install",
> as I have done with many a package.  Then I tried running various programs
> in two directories (these programs are also on the pyglet.org web site).
>
> pyglet-1.2alpha1/examples/programming_guide/hello_world.py runs fine.
>
> pyglet-1.2alpha1/examples/programming_guide/image_viewer.py also runs fine.
>
> pyglet-1.2alpha1/examples/programming_guide/animation.py produces an
> error.  Here's the traceback.
>
...

> From earlier discussions, I know that distutils automatically executes
> 2to3 on the pyglet core module, when you invoke pyglet's setup.py file from
> Python 3.  The setup script does not appear to run 2to3 on the code outside
> of the package itself.  And while I doubted that the KeyError I saw above
> was a Python 2/3 compatibility issue, I tried running 2to3 on animation.py
> anyway.  2to3 seems to agree with me, reporting back "RefactoringTool: No
> files need to be modified."
>
> Finally, I got errors when trying to run pyglet-1.2alpha1/tests/test.py.
>  At first, it looked like the fix would be easy:
>
...

> Clearly this was a problem for 2to3, so I ran it on test.py.  It corrected
> that one print statement, and nothing else.  Then I ran test.py again.
>  This time I got a deeper problem:
>
...

> This error suggests that, during the build and install process, 2to3 left
> some code uncorrected in pyglet/__init__.py.  This has me worried.  Could
> there be other code that 2to3 failed to correct?  I don't want to offer my
> students a tool, only to have it crash on them.
>
> So, there you have it, the two errors that I am encountering.  If anyone
> has any advice, I would appreciate it.  Thanks!
>

Seems relevant:
https://code.google.com/p/pyglet/issues/detail?id=615&colspec=ID%20Stars%20StatusType%20OpSys%20Modified%20Summary


If
https://code.google.com/p/pyglet/issues/detail?id=630&colspec=ID%20Stars%20StatusType%20OpSys%20Modified%20Summary
is
your problem then, for me:

>>> import pyglet
>>> pyglet.window

>>> pyglet.window.Window()


Window pops up.
It works! Sorry.

What happens when you help(pyglet) and help(pyglet.window) and
help(pyglet.window.Window)?
-- 
http://mail.python.org/mailman/listinfo/python-list