Re: [Python-Dev] bytes-like objects

[Nick Coghlan]

On 7 Oct 2014 00:31, "Christian Tismer"  wrote:

>
> 2)
> And about this glossary entry:
>
> "An object that supports the Buffer Protocol"
> - can I take that for granted, as a real definition, meaning
>
> """an object is bytes-like iff it supports the buffer protocol"""?

Yes, although we should likely update it to say the requirement is for
"memoryview(obj)" to work, with the C level buffer protocol being the only
current way to support that on CPython.

Cheers,
Nick.

>
> cheers - Chris
>
> --
> Christian Tismer :^)   tis...@stackless.com
> Software Consulting  : http://www.stackless.com/
> Karl-Liebknecht-Str. 121 : http://www.pydica.net/
> 14482 Potsdam: GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 3.4.2 is slipping by a day

[Larry Hastings]

We don't have Windows installers yet.  If we can't get 'em in the next 
24 hours or so, I'll release without them.  But for now... we wait.


Twiddling my thumbs,


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Interactive Grid for Sorting, Filtering DataFrames in IPython Notebook

[tshawver]

As part of the work on our research environment at  Quantopian
  , I've been building an extension
which renders pandas DataFrames as interactive grids in the IPython
notebook.  The extension uses a Javascript library called SlickGrid to
render the grids, and the current state of the project can be found here on
GitHub: https://github.com/quantopian/qgrid

The extension is also viewable in nbviewer:
http://nbviewer.ipython.org/github/quantopian/qgrid/blob/master/qgrid_demo.ipynb

The GitHub repository contains some explanation of why I chose to implement
the grid as a Python package rather than a standard IPython notebook
extension, which might be interesting for other people who are looking to
add functionality to the notebook in a similar way.

-Tim



--
View this message in context: 
http://python.6.x6.nabble.com/Interactive-Grid-for-Sorting-Filtering-DataFrames-in-IPython-Notebook-tp5073931.html
Sent from the Python - python-dev mailing list archive at Nabble.com.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Interactive Grid for Sorting, Filtering DataFrames in IPython Notebook

[Brett Cannon]

Python-dev is for discussing the development *of* Python, not *with* it.
This kind of thing is more appropriate for python-list.

On Tue Oct 07 2014 at 11:49:37 AM tshawver  wrote:

> As part of the work on our research environment at  Quantopian
>   , I've been building an extension
> which renders pandas DataFrames as interactive grids in the IPython
> notebook.  The extension uses a Javascript library called SlickGrid to
> render the grids, and the current state of the project can be found here on
> GitHub: https://github.com/quantopian/qgrid
>
> The extension is also viewable in nbviewer:
> http://nbviewer.ipython.org/github/quantopian/qgrid/blob/
> master/qgrid_demo.ipynb
>
> The GitHub repository contains some explanation of why I chose to implement
> the grid as a Python package rather than a standard IPython notebook
> extension, which might be interesting for other people who are looking to
> add functionality to the notebook in a similar way.
>
> -Tim
>
>
>
> --
> View this message in context: http://python.6.x6.nabble.com/
> Interactive-Grid-for-Sorting-Filtering-DataFrames-in-
> IPython-Notebook-tp5073931.html
> Sent from the Python - python-dev mailing list archive at Nabble.com.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] performance delta with .py presence v.s. only pyc on python 2.7.x?

[John Smith]

My team has a python app that appears to perform 10+% better when the
python source is present v.s. when only the pyc's are distributed.  This is
contradictory to my understanding of how python leverages pyc's.

Scenario

1. pyc-only install sees mediocre performance. (pyc's are built using
compileall.py, then source .py's removed before packaging)
2. adding the .py files to the installed filesystem results in 10+%
performance improvement
3. verified no difference in mod times, no new .pyc's generated
4. remove the .py's and again see drop in performance


Env info: centos 6.5, x86_64, however python used is 32bit from the i686
repos (this is how we deal with some 32bit only c libraries that the app
must use)


Has anyone got an idea of what I might be running into?  The app itself is
a black box to me.  I was not able to isolate this using a simple piece of
python code that worked on a math problem for a discernible amount of time,
so it could be something to do with how the app is using python.  The app
was originally written for python 2.4...

Any suggestions on what I can try is appreciated.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] performance delta with .py presence v.s. only pyc on python 2.7.x?

[Skip Montanaro]

On Tue, Oct 7, 2014 at 12:46 PM, John Smith  wrote:
> pyc-only install sees mediocre performance. (pyc's are built using
> compileall.py, then source .py's removed before packaging)

(Warning: it's been probably a decade since I looked at any of this
stuff, so treat this response as mere conjecture.)

I'd take a look at startup time and things like stat(2) calls in the
presence or absence of .py files. It's possible that it tries all
other possible file extensions before considering .pyc. If you have a
long sys.path, it would then run through all the other file extension
possibilities before trying the .pyc. OTOH, if the .py is present, it
might be found early in the search, then as an optimization, look for
a .pyc file it can use rather than compiling the .py file. How long is
sys.path?

Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] performance delta with .py presence v.s. only pyc on python 2.7.x?

[Brett Cannon]

On Tue Oct 07 2014 at 2:24:52 PM Skip Montanaro 
wrote:

> On Tue, Oct 7, 2014 at 12:46 PM, John Smith  wrote:
> > pyc-only install sees mediocre performance. (pyc's are built using
> > compileall.py, then source .py's removed before packaging)
>
> (Warning: it's been probably a decade since I looked at any of this
> stuff, so treat this response as mere conjecture.)
>
> I'd take a look at startup time and things like stat(2) calls in the
> presence or absence of .py files. It's possible that it tries all
> other possible file extensions before considering .pyc. If you have a
> long sys.path, it would then run through all the other file extension
> possibilities before trying the .pyc. OTOH, if the .py is present, it
> might be found early in the search, then as an optimization, look for
> a .pyc file it can use rather than compiling the .py file. How long is
> sys.path?
>

The extension check is per sys.path entry so sys.path is the outer loop,
not the file extension list. The relevant code is all in
https://hg.python.org/cpython/file/05f70805f37f/Python/import.c for Python
2.7  and the search code is
https://hg.python.org/cpython/file/05f70805f37f/Python/import.c#l1291 .

But with the code being a black box there is no good way to answer this
question. E.g. if they have a custom finder that is very costly when there
is no source then that could explain this. But you're talking **app**
performance and not import performance, so either something on your system
or in that code is very quirky that is leading to an actual performance
loss to that level (import costs are usually washed out and bytecode is
literally just the internal representation of source after compilation so
there is no semantic difference at execution time if the same source is
used).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com