Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Terry Reedy 

On 9/8/2013 5:41 PM, Guido van Rossum wrote:

On Sun, Sep 8, 2013 at 1:48 PM, Oscar Benjamin
 wrote:

On 8 September 2013 18:32, Guido van Rossum  wrote:

Going over the open issues:

- Parallel arrays or arrays of tuples? I think the API should require
an array of tuples. It is trivial to zip up parallel arrays to the
required format, while if you have an array of tuples, extracting the
parallel arrays is slightly more cumbersome. Also for manipulating of
the raw data, an array of tuples makes it easier to do insertions or
removals without worrying about losing the correspondence between the
arrays.


For something like this, where there are multiple obvious formats for
the input data, I think it's reasonable to just request whatever is
convenient for the implementation.


Not really. The implementation may change, or its needs may not be
obvious to the caller. I would say the right thing to do is request
something easy to remember, which often means consistent. In general,
Python APIs definitely skew towards lists of tuples rather than
parallel arrays, and for good reasons -- that way you benefit most
from built-in operations like slices and insert/append.


This question has been discussed in the statistical software community 
for decades, going back to when storage was on magnetic tape, where 
contiguity was even more important than cache locality. In my experience 
with multiple packages, the most common format for input is tables where 
rows represent cases, samples, or whatever, which translates as lists of 
records (or tuples), just as with relational databases. Columns then 
represent a 'variable'. So I think we should go with that.


Some packages might transpose the data internally, but that is an 
internal matter. The tradeoff is that storing by cases makes adding a 
new case easier, while storing by variables makes adding a new variable 
easier.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Terry Reedy 

On 9/8/2013 10:57 PM, Stephen J. Turnbull wrote:


I don't necessarily find this persuasive.  It's more common when
working with existing databases that you add variables than add
observations.


My experience with general scientific research is the opposite. One 
decides on the variables to measure and then adds rows (records) of data 
as you measure each experimental or observational subject. New 
calculated variables may be added (and often are) after the data 
collection is complete (at least for the moment).


Time series analysis is a distinct and specialized subfield of 
statistics. The corresponding data collections is often different: one 
may start with a fixed set of subjects (50 US states for instance) and 
add 'variables' (population in year X) indefinitely. Much economic 
statistics is in this category.


A third category is interaction analysis, where the data form a true 
matrix where both rows and columns represent subjects and entries 
represent interaction (how many times John emailed Joe, for instance).


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Paul Colomiets 
Hi Guido,

On Sun, Sep 8, 2013 at 8:32 PM, Guido van Rossum  wrote:
> Going over the open issues:
>
> - Parallel arrays or arrays of tuples? I think the API should require
> an array of tuples. It is trivial to zip up parallel arrays to the
> required format, while if you have an array of tuples, extracting the
> parallel arrays is slightly more cumbersome. Also for manipulating of
> the raw data, an array of tuples makes it easier to do insertions or
> removals without worrying about losing the correspondence between the
> arrays.

I think there is a big reason to use parallel arrays that might be
overlooked. You can feed an array.array('f') to the function, which
may save a lot of memory.

--
Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Serhiy Storchaka 

08.09.13 20:52, Guido van Rossum написав(ла):

Well, to me zip(*x) is unnatural, and it's inefficient when the arrays are long.


Perhaps we need zip.from_iterable()?


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Oscar Benjamin 
On 9 September 2013 09:02, Serhiy Storchaka  wrote:
> 08.09.13 20:52, Guido van Rossum написав(ла):
>
>> Well, to me zip(*x) is unnatural, and it's inefficient when the arrays are
>> long.
>
> Perhaps we need zip.from_iterable()?

I would prefer it if chain.from_iterable were named something like
flatten (as it is in the itertools recipes). Similarly transpose is a
better name than zip.from_iterable.


Oscar
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Oscar Benjamin 
On 9 September 2013 04:16, Guido van Rossum  wrote:
>
> Yeah, so this and Steven's review of various other APIs suggests that the
> field of statistics hasn't really reached the object-oriented age (or
> perhaps the OO view isn't suitable for the field), and people really think
> of their data as a matrix of some sort. We should respect that. Now, if this
> was NumPy, it would *still* make sense to require a single argument, to be
> interpreted in the usual fashion. So I'm using that as a kind of leverage to
> still recommend taking a list of pairs instead of a pair of lists. Also,
> it's quite likely that at least *some* of the users of the new statistics
> module will be more familiar with OO programming (e.g. the Python DB API ,
> PEP 249) than they are with other statistics packages.

I'm not sure if I understand what you mean by this. Numpy has built
everything on top of a core ndarray class whose methods make the
issues about multivariate stats APIs trivial. The transpose of an
array A is simply the attribute A.T which is both convenient and cheap
since it's just an alternate view on the underlying buffer.

Also numpy provides record arrays that enable you to use names instead
of numeric indices:

>>> import numpy as np
>>> dt = np.dtype([('Year', int), ('Arizona', float), ('Dakota', float)])
>>> a = np.array([(2001, 123., 456.), (2002, 234., 345), (2003, 345., 567)], dt)
>>> a
array([(2001, 123.0, 456.0), (2002, 234.0, 345.0), (2003, 345.0, 567.0)],
  dtype=[('Year', '>> a['Year']
array([2001, 2002, 2003])
>>> a['Arizona']
array([ 123.,  234.,  345.])
>>> np.corrcoef(a['Arizona'], a['Dakota'])
array([[ 1. ,  0.5],
   [ 0.5,  1. ]])
>>> included = a[a['Year'] > 2001]
>>> included
array([(2002, 234.0, 345.0), (2003, 345.0, 567.0)],
  dtype=[('Year', '>> np.corrcoef(included['Arizona'], included['Dakota'])
array([[ 1.,  1.],
   [ 1.,  1.]])

So perhaps the statistics module could have a similar NameTupleArray
type that can be easily loaded and saved from a csv file and makes it
easy to put your data in whatever form is required.


Oscar
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Offtopic: OpenID Providers

2013-09-09 Thread Stuart Bishop 
On Fri, Sep 6, 2013 at 8:56 AM, Jesus Cea  wrote:

> Sorry, Google, Facebook, Twitter, etc., are not acceptable OpenID
> providers for me. I should have made that point in my original email.
> My excuses.
>
> Any other suggestion?

As Barry mentioned earlier, launchpad.net. Look for the 'lp' icon on
pypi, bugs.python.org etc.


-- 
Stuart Bishop 
http://www.stuartbishop.net/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Skip Montanaro 
> However, it's common in economic statistics to have a rectangular
> array, and extract both certain rows (tuples of observations on
> variables) and certain columns (variables).  For example you might
> have data on populations of American states from 1900 to 2012, and
> extract the data on New England states from 1946 to 2012 for analysis.

When Steven first brought up this PEP on comp.lang.python, my main concern
was basically, "we have SciPy, why do we need this?" Steven's response, which
I have come to accept, is that there are uses for basic statistics for
which SciPy's
stats module would be overkill.

However, once you start slicing your data structure along more than one axis, I
think you very quickly will find that you need numpy arrays for performance
reasons, at which point you might as go "all the way" and install SciPy. I don't
think slicing along multiple dimensions should be a significant concern for this
package.

Alternatively, I thought there was discussion a long time ago about
getting numpy's
(or even further back, numeric's?) array type into the core. Python
has an array type
which I don't think gets a lot of use (or love). Might it be
worthwhile to make sure the
PEP 450 package works with that? Then extend it to multiple dimensions? Or just
bite the bullet and get numpy's array type into the Python core once
and for all?

Sort of Tulip for arrays...

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

Re: [Python-Dev] unicodedata module is out of date

2013-09-09 Thread Martin v. Löwis 
Am 06.09.13 17:55, schrieb Andrew Miller:
> Are there plans to add the extra data from the other UCD files to this
> module?  At the moment I am using a module from
> https://gist.github.com/anonymous/2204527 to obtain the script of a
> character but it would be nice if this was available from the standard
> library.

Well, it is available, and new versions of the UCD are added to new
Python releases. Please consider Python 2 as dead wrt. Unicode support.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unicodedata module is out of date

2013-09-09 Thread Martin v. Löwis 
Am 06.09.13 20:24, schrieb Terry Reedy:
>> In Python 2.7.5 it is set to '5.2.0' so it looks as though this version
>> is no longer being updated.
> 
> In general, new features do not go into bugfix releases (x.y.z, where z
>>= 1). Updating the unidate_version add new features to the unicodedata
> module.
> 

One might argue that an update of the UCD data is within the scope of
2.7, since it's just data, not code that is being changed.

I'd argue against that, since this specific change has a chance of
breaking existing tests that people might have.

Of course, it is up the the release manager of 2.7 to decide on that
if such a change would be proposed.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] DTRACE support

2013-09-09 Thread Martin v. Löwis 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 06.09.13 17:14, schrieb Guido van Rossum:
> I've heard good things about DTRACE but never used it myself.
> 
> Do I understand correctly that you have to build a separate Python 
> executable with it turned on?

My understanding is that you would normally have dtrace support built
on systems that support it. The claim of the dtrace authors is that
there is virtually no overhead in having trace points integrated that
are not active; it achieves that by patching trace instructions over
the NOPs that have been put there during compile time.

Regards,
Martin

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlItsyEACgkQavBT8H2dyNLhNgCfXfgXakq9wgvNGADrYNMvvAJu
05YAn0SxHrOCgoW8k9wjW+ajj+0jtpg9
=E/GT
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASED] Python 3.4.0a2

2013-09-09 Thread Larry Hastings 


On behalf of the Python development team, I'm chuffed to announce the
second alpha release of Python 3.4.

This is a preview release, and its use is not recommended for
production settings.

Python 3.4 includes a range of improvements of the 3.x series, including
hundreds of small improvements and bug fixes.  Major new features and
changes in the 3.4 release series so far include:

* PEP 435, a standardized "enum" module
* PEP 442, improved semantics for object finalization
* PEP 443, adding single-dispatch generic functions to the standard library
* PEP 445, a new C API for implementing custom memory allocators
* PEP 446, changing file descriptors to not be inherited by default
   in subprocesses
* PEP 447, a new magic method for metaclasses (``__typelookup__``)
* PEP 448, making automatic sequence unpacking more general


To download Python 3.4.0a2 visit:

http://www.python.org/download/releases/3.4.0/


Please consider trying Python 3.4.0a2 with your code and reporting any
issues you notice to:

 http://bugs.python.org/


Enjoy!

--
Larry Hastings, Release Manager
larry at hastings.org
(on behalf of the entire python-dev team and 3.4's contributors)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Steven D'Aprano 
On Mon, Sep 09, 2013 at 05:44:43AM -0500, Skip Montanaro wrote:
> > However, it's common in economic statistics to have a rectangular
> > array, and extract both certain rows (tuples of observations on
> > variables) and certain columns (variables).  For example you might
> > have data on populations of American states from 1900 to 2012, and
> > extract the data on New England states from 1946 to 2012 for analysis.
> 
> When Steven first brought up this PEP on comp.lang.python, my main concern
> was basically, "we have SciPy, why do we need this?" Steven's response, which
> I have come to accept, is that there are uses for basic statistics for
> which SciPy's
> stats module would be overkill.
> 
> However, once you start slicing your data structure along more than one axis, 
> I
> think you very quickly will find that you need numpy arrays for performance
> reasons, at which point you might as go "all the way" and install SciPy. I 
> don't
> think slicing along multiple dimensions should be a significant concern for 
> this
> package.

I agree. I'm not interested in trying to compete with numpy in areas 
where numpy is best. That's a fight any pure-Python module is going to 
lose :-)


> Alternatively, I thought there was discussion a long time ago about
> getting numpy's
> (or even further back, numeric's?) array type into the core. Python
> has an array type
> which I don't think gets a lot of use (or love). Might it be
> worthwhile to make sure the
> PEP 450 package works with that? Then extend it to multiple dimensions? Or 
> just
> bite the bullet and get numpy's array type into the Python core once
> and for all?

I haven't tested PEP 450 statistics with numpy array, but any sequence 
type ought to work. While I haven't done extensive testing on the 
array.array type, basic testing shows that it works as expected:

py> import array
py> import statistics
py> data = array.array('f', range(1, 101))
py> statistics.mean(data)
50.5
py> statistics.variance(data)
841.6



-- 
Steven
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.4.0a2

2013-09-09 Thread Brett Cannon 
On Mon, Sep 9, 2013 at 8:02 AM, Larry Hastings  wrote:

>
> On behalf of the Python development team, I'm chuffed to announce the
> second alpha release of Python 3.4.
>
> This is a preview release, and its use is not recommended for
> production settings.
>
> Python 3.4 includes a range of improvements of the 3.x series, including
> hundreds of small improvements and bug fixes.  Major new features and
> changes in the 3.4 release series so far include:
>
> * PEP 435, a standardized "enum" module
> * PEP 442, improved semantics for object finalization
> * PEP 443, adding single-dispatch generic functions to the standard library
> * PEP 445, a new C API for implementing custom memory allocators
> * PEP 446, changing file descriptors to not be inherited by default
>in subprocesses
> * PEP 447, a new magic method for metaclasses (``__typelookup__``)
> * PEP 448, making automatic sequence unpacking more general
>

Those last two PEPs are still in draft form and not accepted nor have any
committed code yet.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Nick Coghlan 
On 9 Sep 2013 20:46, "Skip Montanaro"  wrote:
>
> > However, it's common in economic statistics to have a rectangular
> > array, and extract both certain rows (tuples of observations on
> > variables) and certain columns (variables).  For example you might
> > have data on populations of American states from 1900 to 2012, and
> > extract the data on New England states from 1946 to 2012 for analysis.
>
> When Steven first brought up this PEP on comp.lang.python, my main concern
> was basically, "we have SciPy, why do we need this?" Steven's response,
which
> I have come to accept, is that there are uses for basic statistics for
> which SciPy's
> stats module would be overkill.
>
> However, once you start slicing your data structure along more than one
axis, I
> think you very quickly will find that you need numpy arrays for
performance
> reasons, at which point you might as go "all the way" and install SciPy.
I don't
> think slicing along multiple dimensions should be a significant concern
for this
> package.
>
> Alternatively, I thought there was discussion a long time ago about
> getting numpy's
> (or even further back, numeric's?) array type into the core. Python
> has an array type
> which I don't think gets a lot of use (or love). Might it be
> worthwhile to make sure the
> PEP 450 package works with that? Then extend it to multiple dimensions?
Or just
> bite the bullet and get numpy's array type into the Python core once
> and for all?
>
> Sort of Tulip for arrays...

Aka memoryview :)

Stefan Krah already fixed most of the multidimensional support issues in
3.3 (including the "cast" method to reinterpret the contents in a different
format). The main missing API elements are multidimensional slicing and the
ability to export them from types defined in Python.

Cheers,
Nick.

>
> Skip
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.4.0a2

2013-09-09 Thread Victor Stinner 
2013/9/9 Larry Hastings :
> Python 3.4 includes a range of improvements of the 3.x series, including
> hundreds of small improvements and bug fixes.  Major new features and
> changes in the 3.4 release series so far include:
>
> * PEP 446, changing file descriptors to not be inherited by default
>in subprocesses

The title of the PEP is "Make newly created file descriptors
non-inheritable". It has an impact on all functions creating files and
sockets not only the subprocess module.

You can also add a link to the nice What’s New In Python 3.4 document:
http://docs.python.org/dev/whatsnew/3.4.html

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Oscar Benjamin 
On 9 September 2013 12:56, Nick Coghlan  wrote:
>> Alternatively, I thought there was discussion a long time ago about
>> getting numpy's
>> (or even further back, numeric's?) array type into the core. Python
>> has an array type
>> which I don't think gets a lot of use (or love). Might it be
>> worthwhile to make sure the
>> PEP 450 package works with that? Then extend it to multiple dimensions? Or
>> just
>> bite the bullet and get numpy's array type into the Python core once
>> and for all?
>>
>> Sort of Tulip for arrays...
>
> Aka memoryview :)
>
> Stefan Krah already fixed most of the multidimensional support issues in 3.3
> (including the "cast" method to reinterpret the contents in a different
> format). The main missing API elements are multidimensional slicing and the
> ability to export them from types defined in Python.

Being very familiar with numpy's ndarrays and not so much with
memoryviews this prompted me to go and have a look at them.

How exactly are you supposed to create a multidimensional array using
memoryviews? The best I could come up with was something like:

$ py -3.3
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import array
>>> v = memoryview(array.array('b', [1, 2, 3, 4])).cast('b', (2, 2))
>>> v.shape
(2, 2)

However I don't seem to be able to access the elements:

>>> v[0, 1]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: memoryview: invalid slice key
>>> v[0]
Traceback (most recent call last):
  File "", line 1, in 
NotImplementedError: multi-dimensional sub-views are not implemented
>>> v[0:1]

>>> v[0:1].shape
(1, 2)
>>> v[0:1][0]
Traceback (most recent call last):
  File "", line 1, in 
NotImplementedError: multi-dimensional sub-views are not implemented
>>> v[1]
Traceback (most recent call last):
  File "", line 1, in 
NotImplementedError: multi-dimensional sub-views are not implemented
>>> v[:, 1]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: memoryview: invalid slice key
>>> v[1, :]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: memoryview: invalid slice key

And the .cast method bails if you try to use a more useful type code:

>>> v = memoryview(array.array('q', [1, 2, 3, 4])).cast('q', (2, 2))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: memoryview: cannot cast between two non-byte formats


Oscar
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-09 Thread Nick Coghlan 
On 9 Sep 2013 22:58, "Oscar Benjamin"  wrote:
>
> On 9 September 2013 12:56, Nick Coghlan  wrote:
> >> Alternatively, I thought there was discussion a long time ago about
> >> getting numpy's
> >> (or even further back, numeric's?) array type into the core. Python
> >> has an array type
> >> which I don't think gets a lot of use (or love). Might it be
> >> worthwhile to make sure the
> >> PEP 450 package works with that? Then extend it to multiple
dimensions? Or
> >> just
> >> bite the bullet and get numpy's array type into the Python core once
> >> and for all?
> >>
> >> Sort of Tulip for arrays...
> >
> > Aka memoryview :)
> >
> > Stefan Krah already fixed most of the multidimensional support issues
in 3.3
> > (including the "cast" method to reinterpret the contents in a different
> > format). The main missing API elements are multidimensional slicing and
the
> > ability to export them from types defined in Python.
>
> Being very familiar with numpy's ndarrays and not so much with
> memoryviews this prompted me to go and have a look at them.
>
> How exactly are you supposed to create a multidimensional array using
> memoryviews? The best I could come up with was something like:
>
> $ py -3.3
> Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600
> 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import array
> >>> v = memoryview(array.array('b', [1, 2, 3, 4])).cast('b', (2, 2))
> >>> v.shape
> (2, 2)
>
> However I don't seem to be able to access the elements:
>
> >>> v[0, 1]
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: memoryview: invalid slice key
> >>> v[0]
> Traceback (most recent call last):
>   File "", line 1, in 
> NotImplementedError: multi-dimensional sub-views are not implemented
> >>> v[0:1]
> 
> >>> v[0:1].shape
> (1, 2)
> >>> v[0:1][0]
> Traceback (most recent call last):
>   File "", line 1, in 
> NotImplementedError: multi-dimensional sub-views are not implemented
> >>> v[1]
> Traceback (most recent call last):
>   File "", line 1, in 
> NotImplementedError: multi-dimensional sub-views are not implemented
> >>> v[:, 1]
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: memoryview: invalid slice key
> >>> v[1, :]
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: memoryview: invalid slice key
>
> And the .cast method bails if you try to use a more useful type code:
>
> >>> v = memoryview(array.array('q', [1, 2, 3, 4])).cast('q', (2, 2))
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: memoryview: cannot cast between two non-byte formats

Oops, forgot the type casting restrictions, too.

My main point was that PEP 3118 is already intended as the tulip equivalent
for multi-dimensional arrays, and memoryview is the stdlib API for that.
It's just incomplete, since most serious multi-dimensional use cases
involve skipping memoryview and go straight to NumPy or one of the image
libraries.

As far as I am aware, there's no opposition to fixing the multi-dimensional
support in memoryview *per se*, just the usual concerns about
maintainability and a question of volunteers with the time to actually
resolve the relevant open issues on the bug tracker. The fairly extensive
3.3 changes focused on fixing stuff that was previously outright broken,
but several limitations remain, often because the best API wasn't clear, or
because it reached the point where "just use NumPy" seemed like a
justifiable answer.

Cheers,
Nick.

>
>
> Oscar
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Post-3.4.0a2-release fixups.

2013-09-09 Thread Nick Coghlan 
On 9 Sep 2013 22:15, "larry.hastings"  wrote:
>
> http://hg.python.org/cpython/rev/6b211a0c8042
> changeset:   85645:6b211a0c8042
> user:Larry Hastings 
> date:Mon Sep 09 21:08:52 2013 +0900
> summary:
>   Post-3.4.0a2-release fixups.
>
> files:
>   Include/patchlevel.h |   2 +-
>   Misc/NEWS|  14 +-
>   2 files changed, 14 insertions(+), 2 deletions(-)
>
>
> diff --git a/Include/patchlevel.h b/Include/patchlevel.h
> --- a/Include/patchlevel.h
> +++ b/Include/patchlevel.h
> @@ -23,7 +23,7 @@
>  #define PY_RELEASE_SERIAL  2
>
>  /* Version as a string */
> -#define PY_VERSION "3.4.0a2"
> +#define PY_VERSION "3.4.0a2+"
>  /*--end constants--*/
>
>  /* Version as a single 4-byte hex number, e.g. 0x010502B2 == 1.5.2b2.
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -2,10 +2,22 @@
>  Python News
>  +++
>
> +What's New in Python 3.4.0 Alpha 3?
> +===
> +
> +Projected Release date: 2013-09-29
> +
> +Core and Builtins
> +-
> +
> +Library
> +---
> +
> +

I had already pushed alpha 3 entries in NEWS, so something seems to have
gone wrong here.

Perhaps, if RMs are preparing the release out of tree, we could get the
NEWS file headings on default updated immediately after the last included
commit?

Cheers,
Nick.

>  What's New in Python 3.4.0 Alpha 2?
>  ===
>
> -Projected Release date: 2013-09-08
> +Release date: 2013-09-09
>
>  Core and Builtins
>  -
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-checkins
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.4.0a2

2013-09-09 Thread R. David Murray 
On Mon, 09 Sep 2013 14:45:51 +0200, Antoine Pitrou  wrote:
> Le Mon, 9 Sep 2013 14:30:50 +0200,
> Victor Stinner  a écrit :
> > 2013/9/9 Larry Hastings :
> > > Python 3.4 includes a range of improvements of the 3.x series,
> > > including hundreds of small improvements and bug fixes.  Major new
> > > features and changes in the 3.4 release series so far include:
> > >
> > > * PEP 446, changing file descriptors to not be inherited by default
> > >in subprocesses
> > 
> > The title of the PEP is "Make newly created file descriptors
> > non-inheritable". It has an impact on all functions creating files and
> > sockets not only the subprocess module.
> 
> I don't think Larry's description is wrong. "Non-inheritable" is a
> shorthand for "non-inheritable in subprocesses" with "subprocesses"
> taken in the general sense (i.e. not only created with the subprocess
> module).

Not wrong, but definitely confusing.  It is worth clarifying *somehow*
that this does not apply only to the subprocess module, which is what
a naive (or fast) reader will assume.

--David
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Ethan Furman 

On 07/30/2013 11:17 PM, Ronald Oussoren wrote:


And something I forgot to ask: is anyone willing to be the BDFL-Delegate for
PEP 447?


*Bump*.

It would be nice if this could make into 3.4.

--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Offtopic: OpenID Providers

2013-09-09 Thread Jesus Cea 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 21:34, R. David Murray wrote:
> Note that I said that single signon *itself* was overrated.  If you
> use the same token to authenticate to multiple sites (and here the
> 'token' is the email address) then your identities on those sites
> are ipso facto associated with each other.  *If* that email address
> is also never leaked (never displayed, even to other signed on
> users, all communication with the site encrypted), then you only
> have to worry if the sites exchange information about their
> accounts, or if the government comes knocking on their doors
> 
> Yes, I'm paranoid.  That doesn't mean they aren't listening.

Being paranoid is good. Fix for this is actually trivial: Use
different emails for different "personalities".

If you are doing things you really NEED to hide, virtual machines and
TOR is the way to go.

- -- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:[email protected]  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUi3lGZlgi5GaxT1NAQLykAQAi8WDuWmEAAX7bP1glDT8iLrMRpKlu+Vh
WndX9ObB/os2D9RZkL7DZB01EDMRvfjGlWFm3gQV0CbM9smkgGkhJNLuxYzA2fpK
PQlbO4KUKCoQG7qm413TA1g0xxOGzG2n9g2kJisFBCNu2Y2PXroUhm6p41CbTd89
ovwZLLUcPZU=
=EQu4
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Guido van Rossum 
Let's just accept this PEP. It looks like a nice addition to the metaclass
machinery and I don't think we'll get much more useful feedback by waiting.


On Mon, Sep 9, 2013 at 7:30 AM, Ethan Furman  wrote:

> On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
>
>>
>> And something I forgot to ask: is anyone willing to be the BDFL-Delegate
>> for
>> PEP 447?
>>
>
> *Bump*.
>
> It would be nice if this could make into 3.4.
>
> --
> ~Ethan~
>
> __**_
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/**mailman/options/python-dev/**
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Guido van Rossum 
OK, how much time do you need?

--Guido van Rossum (sent from Android phone)
On Sep 9, 2013 8:44 AM, "Mark Shannon"  wrote:

> I would like time to investigate this further, but at the moment I think
> it will either make attribute lookup poorly defined or slow.
>
> Of the top of my head, the problem as a I see it is basically this:
> Currently, type.__getattribute__() is a fixed point in the lookup of
> attributes.
> The proposal means that a fixed point is not reached until the cls
> parameter of type.__getattribute__() is either object or type,
> otherwise type.__getattribute__() and type.__locallookup__ must bounce
> back and forth.
>
> This will slow down *every* attribute lookup for what is a fairly obscure
> use case.
>
> Cheers,
> Mark.
>
> On 09/09/13 16:27, Guido van Rossum wrote:
>
>> Let's just accept this PEP. It looks like a nice addition to the
>> metaclass machinery and I don't think we'll get much more useful feedback
>> by waiting.
>>
>>
>> On Mon, Sep 9, 2013 at 7:30 AM, Ethan Furman > [email protected]>> wrote:
>>
>> On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
>>
>>
>> And something I forgot to ask: is anyone willing to be the
>> BDFL-Delegate for
>> PEP 447?
>>
>>
>> *Bump*.
>>
>> It would be nice if this could make into 3.4.
>>
>> --
>> ~Ethan~
>>
>> __**___
>> Python-Dev mailing list
>> [email protected] 
>> 
>> https://mail.python.org/__**mailman/listinfo/python-dev<
>> https://mail.python.org/**mailman/listinfo/python-dev
>> >
>> Unsubscribe: https://mail.python.org/__**
>> mailman/options/python-dev/__**guido%40python.org<
>> https://mail.python.org/**mailman/options/python-dev/**guido%40python.org
>> >
>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido )
>>
>>
>> __**_
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/**mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/**mailman/options/python-dev/**
>> mark%40hotpy.org
>>
>>  __**_
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/**mailman/options/python-dev/**
> guido%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Mark Shannon 

I'll look into it this evening.

On 09/09/13 17:03, Guido van Rossum wrote:

OK, how much time do you need?

--Guido van Rossum (sent from Android phone)

On Sep 9, 2013 8:44 AM, "Mark Shannon" mailto:[email protected]>> 
wrote:

I would like time to investigate this further, but at the moment I think it 
will either make attribute lookup poorly defined or slow.

Of the top of my head, the problem as a I see it is basically this:
Currently, type.__getattribute__() is a fixed point in the lookup of 
attributes.
The proposal means that a fixed point is not reached until the cls 
parameter of type.__getattribute__() is either object or type,
otherwise type.__getattribute__() and type.__locallookup__ must bounce back 
and forth.

This will slow down *every* attribute lookup for what is a fairly obscure 
use case.

Cheers,
Mark.

On 09/09/13 16:27, Guido van Rossum wrote:

Let's just accept this PEP. It looks like a nice addition to the 
metaclass machinery and I don't think we'll get much more useful feedback by 
waiting.


On Mon, Sep 9, 2013 at 7:30 AM, Ethan Furman mailto:[email protected]> >> wrote:

 On 07/30/2013 11:17 PM, Ronald Oussoren wrote:


 And something I forgot to ask: is anyone willing to be the 
BDFL-Delegate for
 PEP 447?


 *Bump*.

 It would be nice if this could make into 3.4.

 --
 ~Ethan~

 ___
 Python-Dev mailing list
[email protected]  
>
https://mail.python.org/mailman/listinfo/python-dev 
 
>
 Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/guido%40python.org 

>




--
--Guido van Rossum (python.org/~guido  
)


_
Python-Dev mailing list
[email protected] 
https://mail.python.org/__mailman/listinfo/python-dev 

Unsubscribe: 
https://mail.python.org/__mailman/options/python-dev/__mark%40hotpy.org 


_
Python-Dev mailing list
[email protected] 
https://mail.python.org/__mailman/listinfo/python-dev 

Unsubscribe: 
https://mail.python.org/__mailman/options/python-dev/__guido%40python.org 



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Post-3.4.0a2-release fixups.

2013-09-09 Thread Benjamin Peterson 
Well, it's important for the release manager to make sure what the
script is doing is sane. :)

2013/9/9 Nick Coghlan :
>
> On 9 Sep 2013 22:15, "larry.hastings"  wrote:
>>
>> http://hg.python.org/cpython/rev/6b211a0c8042
>> changeset:   85645:6b211a0c8042
>> user:Larry Hastings 
>> date:Mon Sep 09 21:08:52 2013 +0900
>> summary:
>>   Post-3.4.0a2-release fixups.
>>
>> files:
>>   Include/patchlevel.h |   2 +-
>>   Misc/NEWS|  14 +-
>>   2 files changed, 14 insertions(+), 2 deletions(-)
>>
>>
>> diff --git a/Include/patchlevel.h b/Include/patchlevel.h
>> --- a/Include/patchlevel.h
>> +++ b/Include/patchlevel.h
>> @@ -23,7 +23,7 @@
>>  #define PY_RELEASE_SERIAL  2
>>
>>  /* Version as a string */
>> -#define PY_VERSION "3.4.0a2"
>> +#define PY_VERSION "3.4.0a2+"
>>  /*--end constants--*/
>>
>>  /* Version as a single 4-byte hex number, e.g. 0x010502B2 == 1.5.2b2.
>> diff --git a/Misc/NEWS b/Misc/NEWS
>> --- a/Misc/NEWS
>> +++ b/Misc/NEWS
>> @@ -2,10 +2,22 @@
>>  Python News
>>  +++
>>
>> +What's New in Python 3.4.0 Alpha 3?
>> +===
>> +
>> +Projected Release date: 2013-09-29
>> +
>> +Core and Builtins
>> +-
>> +
>> +Library
>> +---
>> +
>> +
>
> I had already pushed alpha 3 entries in NEWS, so something seems to have
> gone wrong here.
>
> Perhaps, if RMs are preparing the release out of tree, we could get the NEWS
> file headings on default updated immediately after the last included commit?
>
> Cheers,
> Nick.
>
>>  What's New in Python 3.4.0 Alpha 2?
>>  ===
>>
>> -Projected Release date: 2013-09-08
>> +Release date: 2013-09-09
>>
>>  Core and Builtins
>>  -
>>
>> --
>> Repository URL: http://hg.python.org/cpython
>>
>> ___
>> Python-checkins mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-checkins
>>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org
>



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Post-3.4.0a2-release fixups.

2013-09-09 Thread Nick Coghlan 
On 10 Sep 2013 01:32, "Benjamin Peterson"  wrote:
>
> Well, it's important for the release manager to make sure what the
> script is doing is sane. :)

Sure, preparing out of tree is fine and sensible. But we should either
freeze the tree or update the NEWS headers immediately, otherwise we're
going to have updates going into the wrong section.

Cheers,
Nick.

>
> 2013/9/9 Nick Coghlan :
> >
> > On 9 Sep 2013 22:15, "larry.hastings" 
wrote:
> >>
> >> http://hg.python.org/cpython/rev/6b211a0c8042
> >> changeset:   85645:6b211a0c8042
> >> user:Larry Hastings 
> >> date:Mon Sep 09 21:08:52 2013 +0900
> >> summary:
> >>   Post-3.4.0a2-release fixups.
> >>
> >> files:
> >>   Include/patchlevel.h |   2 +-
> >>   Misc/NEWS|  14 +-
> >>   2 files changed, 14 insertions(+), 2 deletions(-)
> >>
> >>
> >> diff --git a/Include/patchlevel.h b/Include/patchlevel.h
> >> --- a/Include/patchlevel.h
> >> +++ b/Include/patchlevel.h
> >> @@ -23,7 +23,7 @@
> >>  #define PY_RELEASE_SERIAL  2
> >>
> >>  /* Version as a string */
> >> -#define PY_VERSION "3.4.0a2"
> >> +#define PY_VERSION "3.4.0a2+"
> >>  /*--end constants--*/
> >>
> >>  /* Version as a single 4-byte hex number, e.g. 0x010502B2 == 1.5.2b2.
> >> diff --git a/Misc/NEWS b/Misc/NEWS
> >> --- a/Misc/NEWS
> >> +++ b/Misc/NEWS
> >> @@ -2,10 +2,22 @@
> >>  Python News
> >>  +++
> >>
> >> +What's New in Python 3.4.0 Alpha 3?
> >> +===
> >> +
> >> +Projected Release date: 2013-09-29
> >> +
> >> +Core and Builtins
> >> +-
> >> +
> >> +Library
> >> +---
> >> +
> >> +
> >
> > I had already pushed alpha 3 entries in NEWS, so something seems to have
> > gone wrong here.
> >
> > Perhaps, if RMs are preparing the release out of tree, we could get the
NEWS
> > file headings on default updated immediately after the last included
commit?
> >
> > Cheers,
> > Nick.
> >
> >>  What's New in Python 3.4.0 Alpha 2?
> >>  ===
> >>
> >> -Projected Release date: 2013-09-08
> >> +Release date: 2013-09-09
> >>
> >>  Core and Builtins
> >>  -
> >>
> >> --
> >> Repository URL: http://hg.python.org/cpython
> >>
> >> ___
> >> Python-checkins mailing list
> >> [email protected]
> >> https://mail.python.org/mailman/listinfo/python-checkins
> >>
> >
> >
> > ___
> > Python-Dev mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > https://mail.python.org/mailman/options/python-dev/benjamin%40python.org
> >
>
>
>
> --
> Regards,
> Benjamin
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Mark Shannon 

I would like time to investigate this further, but at the moment I think it 
will either make attribute lookup poorly defined or slow.

Of the top of my head, the problem as a I see it is basically this:
Currently, type.__getattribute__() is a fixed point in the lookup of attributes.
The proposal means that a fixed point is not reached until the cls parameter of 
type.__getattribute__() is either object or type,
otherwise type.__getattribute__() and type.__locallookup__ must bounce back and 
forth.

This will slow down *every* attribute lookup for what is a fairly obscure use 
case.

Cheers,
Mark.

On 09/09/13 16:27, Guido van Rossum wrote:

Let's just accept this PEP. It looks like a nice addition to the metaclass 
machinery and I don't think we'll get much more useful feedback by waiting.


On Mon, Sep 9, 2013 at 7:30 AM, Ethan Furman mailto:[email protected]>> wrote:

On 07/30/2013 11:17 PM, Ronald Oussoren wrote:


And something I forgot to ask: is anyone willing to be the 
BDFL-Delegate for
PEP 447?


*Bump*.

It would be nice if this could make into 3.4.

--
~Ethan~

_
Python-Dev mailing list
[email protected] 
https://mail.python.org/__mailman/listinfo/python-dev 

Unsubscribe: 
https://mail.python.org/__mailman/options/python-dev/__guido%40python.org 





--
--Guido van Rossum (python.org/~guido )


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/mark%40hotpy.org


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Ethan Furman 

On 09/09/2013 08:43 AM, Mark Shannon wrote:

I would like time to investigate this further, but at the moment I think it 
will either make attribute lookup poorly
defined or slow.

Of the top of my head, the problem as a I see it is basically this:
Currently, type.__getattribute__() is a fixed point in the lookup of attributes.
The proposal means that a fixed point is not reached until the cls parameter of 
type.__getattribute__() is either object
or type,
otherwise type.__getattribute__() and type.__locallookup__ must bounce back and 
forth.

This will slow down *every* attribute lookup for what is a fairly obscure use 
case.


Looks like there's a patch we can try at http://bugs.python.org/issue18181.

Here are Ronald's last timings:


---
PYBENCH 2.1

---
* using CPython 3.4.0a0 (default, Jul 29 2013, 13:01:34) [GCC 4.4.7 
20120313 (Red Hat 4.4.7-3)]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.perf_counter
* timer: resolution=1e-09, implementation=clock_gettime(CLOCK_MONOTONIC)


---
Benchmark: pep447.pybench

---

Rounds: 10
Warp:   10
Timer:  time.perf_counter

Machine Details:
   Platform ID:
Linux-2.6.32-358.114.1.openstack.el6.x86_64-x86_64-with-centos-6.4-Final
   Processor:  x86_64

Python:
   Implementation: CPython
   Executable: /tmp/default-pep447/bin/python3
   Version:3.4.0a0
   Compiler:   GCC 4.4.7 20120313 (Red Hat 4.4.7-3)
   Bits:   64bit
   Build:  Jul 29 2013 14:09:12 (#default)
   Unicode:UCS4



---
Comparing with: default.pybench

---

Rounds: 10
Warp:   10
Timer:  time.perf_counter

Machine Details:
   Platform ID:
Linux-2.6.32-358.114.1.openstack.el6.x86_64-x86_64-with-centos-6.4-Final
   Processor:  x86_64

Python:
   Implementation: CPython
   Executable: /tmp/default/bin/python3
   Version:3.4.0a0
   Compiler:   GCC 4.4.7 20120313 (Red Hat 4.4.7-3)
   Bits:   64bit
   Build:  Jul 29 2013 13:01:34 (#default)
   Unicode:UCS4


Test minimum run-timeaverage  
run-time
 thisother   diffthisother  
 diff

---
  BuiltinFunctionCalls:45ms44ms   +1.3%45ms44ms 
  +1.3%
   BuiltinMethodLookup:26ms27ms   -2.4%27ms27ms 
  -2.2%
 CompareFloats:33ms34ms   -0.7%33ms34ms 
  -1.1%
 CompareFloatsIntegers:66ms67ms   -0.9%66ms67ms 
  -0.8%
   CompareIntegers:51ms50ms   +0.9%51ms50ms 
  +0.8%
CompareInternedStrings:34ms33ms   +0.4%34ms34ms 
  -0.4%
  CompareLongs:29ms29ms   -0.1%29ms29ms 
  -0.0%
CompareStrings:43ms44ms   -1.8%44ms44ms 
  -1.8%
ComplexPythonFunctionCalls:44ms42ms   +3.9%44ms42ms 
  +4.1%
 ConcatStrings:33ms33ms   -0.4%33ms33ms 
  -1.0%
   CreateInstances:47ms48ms   -2.9%47ms49ms 
  -3.4%
CreateNewInstances:35ms36ms   -2.5%36ms36ms 
  -2.5%
   CreateStringsWithConcat:69ms70ms   -0.7%69ms70ms 
  -0.9%
  DictCreation:52ms50ms   +3.1%52ms50ms 
  +3.0%
 DictWithFloatKeys:40ms44ms  -10.1%43ms45ms 
  -5.8%
   DictWithIntegerKeys:32ms36ms  -11.2%35ms37ms 
  -4.6%
DictWithStringKeys:29ms34ms  -15.7%35ms40ms 
 -11.0%
  ForLoops:30ms29ms   +2.2%30ms29ms 
  +2.2%
IfThenElse:38ms41ms   -6.7%38ms41ms 
  -6.9%
   ListSlicing:36ms36ms   -0.7%36ms37ms 
  -1.3%

Re: [Python-Dev] Offtopic: paranoia

2013-09-09 Thread R. David Murray 
On Mon, 09 Sep 2013 17:11:21 +0200, Jesus Cea  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 06/09/13 21:34, R. David Murray wrote:
> > Note that I said that single signon *itself* was overrated.  If you
> > use the same token to authenticate to multiple sites (and here the
> > 'token' is the email address) then your identities on those sites
> > are ipso facto associated with each other.  *If* that email address
> > is also never leaked (never displayed, even to other signed on
> > users, all communication with the site encrypted), then you only
> > have to worry if the sites exchange information about their
> > accounts, or if the government comes knocking on their doors
> > 
> > Yes, I'm paranoid.  That doesn't mean they aren't listening.
> 
> Being paranoid is good. Fix for this is actually trivial: Use
> different emails for different "personalities".

Yes, that's exactly my point.

> If you are doing things you really NEED to hide, virtual machines and
> TOR is the way to go.

Well, it would helpful if a lot more people started routing traffic
through TOR even when they didn't NEED to.  I plan to start doing so soon.

--David
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Offtopic: OpenID Providers

2013-09-09 Thread Oleg Broytman 
On Mon, Sep 09, 2013 at 10:39:11AM -0700, Toshio Kuratomi  
wrote:
> So OpenID fails as a truly generic SSO method across sites on the
> internet... what have we found it good for then?  SSO within our site.

   I.e., OpenID could be good for core developers (using @python.org
email adresses as IDs) but not for general public to login to pydotorg
sites, right?

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Antoine Pitrou 
On Mon, 09 Sep 2013 09:05:57 -0700
Ethan Furman  wrote:
> On 09/09/2013 08:43 AM, Mark Shannon wrote:
> > I would like time to investigate this further, but at the moment I think it 
> > will either make attribute lookup poorly
> > defined or slow.
> >
> > Of the top of my head, the problem as a I see it is basically this:
> > Currently, type.__getattribute__() is a fixed point in the lookup of 
> > attributes.
> > The proposal means that a fixed point is not reached until the cls 
> > parameter of type.__getattribute__() is either object
> > or type,
> > otherwise type.__getattribute__() and type.__locallookup__ must bounce back 
> > and forth.
> >
> > This will slow down *every* attribute lookup for what is a fairly obscure 
> > use case.
> 
> Looks like there's a patch we can try at http://bugs.python.org/issue18181.
> 
> Here are Ronald's last timings:

Thanks but can you run a benchmark that actually exercises the feature?
(I don't know enough about it to know what that would be, but I suppose
it has to do with lookups on classes, rather than on instances)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Offtopic: OpenID Providers

2013-09-09 Thread Oleg Broytman 
On Mon, Sep 09, 2013 at 09:46:58PM +0400, Oleg Broytman  wrote:
> On Mon, Sep 09, 2013 at 10:39:11AM -0700, Toshio Kuratomi 
>  wrote:
> > So OpenID fails as a truly generic SSO method across sites on the
> > internet... what have we found it good for then?  SSO within our site.
> 
>I.e., OpenID could be good for core developers (using @python.org
> email adresses as IDs) but not for general public to login to pydotorg
> sites, right?

   Oops, completely messed OpenID URLs and Persona emails.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Offtopic: OpenID Providers

2013-09-09 Thread Toshio Kuratomi 
On Thu, Sep 5, 2013 at 6:09 PM, Stephen J. Turnbull  wrote:
> Barry Warsaw writes:

>  > We're open source, and I think it benefits our mission to support open,
>  > decentralized, and free systems like OpenID and Persona.
>
> Thus speaks an employee of yet another Provider-That-Won't-Accept-My-
> Third-Party-Credentials.  Sorry, Barry, but you see the problem:
> Unfortunately, we can't do it alone.  What needs to happen is there
> needs to be a large network of sites that support login via O-D-F
> systems like OpenID and Persona.  Too many of the sites I use (news
> sources, GMail, etc) don't support them and my browser manages my
> logins to most of them, so why bother learning OpenID, and then
> setting it up site by site?
>
[snipped lots of observations that I generally agree with]

There's been a lot of negativity towards OpenID in this thread -- I'd
like to say that in Fedora Infrastructure we've found OpenID to be
very very good -- but not at addressing the problem that most people
are after here.  As you've observed being an OpenID provider is a
relatively easy to swallow proposition; accepting OpenID from third
parties is another thing entirely.  As you've also observed, this has
to do with trust.  A site can trust their own account system and
practices and issue OpenID based on those.  It is much riskier for the
site to trust someone else's account system and practices when
deciding whether a user is actually the owner of the account that they
claim.

So OpenID fails as a truly generic SSO method across sites on the
internet... what have we found it good for then?  SSO within our site.
 More and more apps support OpenID out of the box.  Many web
frameworks have modules for the code you write to authenticate against
an OpenID server.  A site configures these apps and modules to only
trust the site's OpenID service and then deploys them with less custom
code.  Sites also get a choice about how much risk they consider
compromised accounts to a particular application.  If they run a web
forum and a build system for instance, they might constrain the build
system to only their OpenID service but allow the forum to allow
OpenID from other providers. And finally, having an openid service
lets their users sign into more trusting sites like python.org
properties (unlike say, LDAP) :-)

-Toshio
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Jan Kaliszewski 
Is '__locallookup__' a really good name? In Python, *local* -- 
especially in context of *lookups* -- usually associates with locals() 
i.e. a namespace of a function/method execution frame or a namespace of 
a class, during *definition* of that class... So '__locallookup__' can 
be confusing.


Why not just '__getclassattribute__' or '__classlookup__', or 
'__classattribute__'...?


Cheers.
*j

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.4.0a2

2013-09-09 Thread Ned Deily 
In article <[email protected]>,
 Larry Hastings  wrote:

> On behalf of the Python development team, I'm chuffed to announce the
> second alpha release of Python 3.4.

Yay!  3.4.0a2 also contains a new batteries-included feature for OS X 
users.  The python.org 64-bit/32-bit installer now includes its own 
private version of Tcl/Tk 8.5.14 so it is finally no longer necessary to 
install a third-party version of Tcl/Tk 8.5 to workaround the 
problematic system versions shipped in OS X 10.6+.  More improvements to 
come.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.4.0a2

2013-09-09 Thread Victor Stinner 
2013/9/9 Antoine Pitrou :
> Le Mon, 9 Sep 2013 14:30:50 +0200,
> Victor Stinner  a écrit :
>> 2013/9/9 Larry Hastings :
>> > Python 3.4 includes a range of improvements of the 3.x series,
>> > including hundreds of small improvements and bug fixes.  Major new
>> > features and changes in the 3.4 release series so far include:
>> >
>> > * PEP 446, changing file descriptors to not be inherited by default
>> >in subprocesses
>>
>> The title of the PEP is "Make newly created file descriptors
>> non-inheritable". It has an impact on all functions creating files and
>> sockets not only the subprocess module.
>
> I don't think Larry's description is wrong. "Non-inheritable" is a
> shorthand for "non-inheritable in subprocesses" with "subprocesses"
> taken in the general sense (i.e. not only created with the subprocess
> module).

Oh, I misunderstood "in subprocesses", I read "in the subprocess module".

The definition of FD inheritance is tricky. For example, on UNIX
"non-inheritable" file descriptors are still inherited at fork :-)

I hope that the documentation is explicit enough:
http://docs.python.org/dev/library/os.html#inheritance-of-file-descriptors

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Yury Selivanov 
Yes, I don't like the 'local' prefix too.  How about '__dictlookup__'?
It's just more self-describing.

Yury

On 2013-09-09, at 2:23 PM, Jan Kaliszewski  wrote:

> Is '__locallookup__' a really good name? In Python, *local* -- especially in 
> context of *lookups* -- usually associates with locals() i.e. a namespace of 
> a function/method execution frame or a namespace of a class, during 
> *definition* of that class... So '__locallookup__' can be confusing.
> 
> Why not just '__getclassattribute__' or '__classlookup__', or 
> '__classattribute__'...?
> 
> Cheers.
> *j
> 
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Benjamin Peterson 
Since the main problem is super(), maybe we can just add a __super__
method to get a custom super implementation?

2013/9/9 Ethan Furman :
> On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
>>
>>
>> And something I forgot to ask: is anyone willing to be the BDFL-Delegate
>> for
>> PEP 447?
>
>
> *Bump*.
>
> It would be nice if this could make into 3.4.
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Mark Shannon 

On 09/09/13 15:30, Ethan Furman wrote:

On 07/30/2013 11:17 PM, Ronald Oussoren wrote:


And something I forgot to ask: is anyone willing to be the
BDFL-Delegate for
PEP 447?


*Bump*.

It would be nice if this could make into 3.4.



IMO, there are some issues that need to be addressed before PEP 447 
should be accepted.


1. Is there even a problem at all, or is this just a bug in super?
Why doesn't super() respect the __getattribute__ method of the superclass?

2. Is this the best way to solve the problem (if there is a problem)?
Would a __super__ special method be sufficient and less intrusive.

3. Are the proposed semantics OK?
I think they are, but very low level changes such as these can have 
unforeseen consequences. For example, PEP 3135 and issue 12370.


4. What is the performance impact. pybench really doesn't count as a 
benchmark.


5. Other implementations. What do the Jython/IronPython/PyPy developers 
think?



Cheers,
Mark.

p.s.
Apologies for top-posting earlier
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Benjamin Peterson 
2013/9/9 Mark Shannon :
> On 09/09/13 15:30, Ethan Furman wrote:
>>
>> On 07/30/2013 11:17 PM, Ronald Oussoren wrote:
>>>
>>>
>>> And something I forgot to ask: is anyone willing to be the
>>> BDFL-Delegate for
>>> PEP 447?
>>
>>
>> *Bump*.
>>
>> It would be nice if this could make into 3.4.
>>
>
> IMO, there are some issues that need to be addressed before PEP 447 should
> be accepted.
>
> 1. Is there even a problem at all, or is this just a bug in super?
> Why doesn't super() respect the __getattribute__ method of the superclass?

You want to be looking things up on the class, not an instance.

-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: add type.__locallookup__

2013-09-09 Thread Mark Shannon 

On 09/09/13 22:25, Benjamin Peterson wrote:

2013/9/9 Mark Shannon :

On 09/09/13 15:30, Ethan Furman wrote:


On 07/30/2013 11:17 PM, Ronald Oussoren wrote:



And something I forgot to ask: is anyone willing to be the
BDFL-Delegate for
PEP 447?



*Bump*.

It would be nice if this could make into 3.4.



IMO, there are some issues that need to be addressed before PEP 447 should
be accepted.

1. Is there even a problem at all, or is this just a bug in super?
Why doesn't super() respect the __getattribute__ method of the superclass?


You want to be looking things up on the class, not an instance.


Sorry, I meant 'type of the superclass' rather than 'superclass'.

I was suggesting that super().m should be 
type(type(self).__mro__[1]).__getattribute__('m')

rather than type(self).__mro__[1].__dict__['m']
(ignoring descriptor __get__ calls)

Unfortunately this brings its own problems, due to __getattribute__ 
doing its own traversal of the mro.

So, scratch point 1.

Cheers,
Mark.



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.4.0a2

2013-09-09 Thread Ryan 
HALLELUJAH!!!

Ned Deily  wrote:

>In article <[email protected]>,
> Larry Hastings  wrote:
>
>> On behalf of the Python development team, I'm chuffed to announce the
>> second alpha release of Python 3.4.
>
>Yay!  3.4.0a2 also contains a new batteries-included feature for OS X 
>users.  The python.org 64-bit/32-bit installer now includes its own 
>private version of Tcl/Tk 8.5.14 so it is finally no longer necessary
>to 
>install a third-party version of Tcl/Tk 8.5 to workaround the 
>problematic system versions shipped in OS X 10.6+.  More improvements
>to 
>come.
>
>-- 
> Ned Deily,
> [email protected]
>
>___
>Python-Dev mailing list
>[email protected]
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.4.0a2

2013-09-09 Thread Stefan Behnel 
Ned Deily, 09.09.2013 21:29:
> 3.4.0a2 also contains a new batteries-included feature for OS X 
> users.  The python.org 64-bit/32-bit installer now includes its own 
> private version of Tcl/Tk 8.5.14 so it is finally no longer necessary to 
> install a third-party version of Tcl/Tk 8.5 to workaround the 
> problematic system versions shipped in OS X 10.6+.  More improvements to 
> come.

With MS Windows on steep decline, I'm so happy we have at least MacOS-X
rising to keep us busy.

Stefan


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (2.7): Clarify mmap.close method behavior. Addresses issue #18815

2013-09-09 Thread Antoine Pitrou 
On Tue, 10 Sep 2013 07:40:21 +0200 (CEST)
senthil.kumaran  wrote:
> http://hg.python.org/cpython/rev/443d12b61e5b
> changeset:   85653:443d12b61e5b
> branch:  2.7
> parent:  85639:740bd510a888
> user:Senthil Kumaran 
> date:Mon Sep 09 22:38:58 2013 -0700
> summary:
>   Clarify mmap.close method  behavior.  Addresses issue  #18815
> Patch contributed by Anoop Thomas Mathew.
> 
> files:
>   Doc/library/mmap.rst |  5 +++--
>   1 files changed, 3 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/Doc/library/mmap.rst b/Doc/library/mmap.rst
> --- a/Doc/library/mmap.rst
> +++ b/Doc/library/mmap.rst
> @@ -152,8 +152,9 @@
>  
> .. method:: close()
>  
> -  Close the file.  Subsequent calls to other methods of the object will
> -  result in an exception being raised.
> +  Closes the mmap. Subsequent calls to other methods of the object will
> +  result in a ValueError exception being raised. This will not close
> +  the open file.

I think this could be improved.  Anonymous mmap objects don't have an
"open file". Also, it would be clearer if it read "the underlying file"
rather than "the underlying file object" rather than "the open file",
because an mmap object is a file as well (it has read(), write(),
seek(), etc.).

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com