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:
> Clari
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 workaro
HALLELUJAH!!!
Ned Deily wrote:
>In article <522db8d3.1030...@hastings.org>,
> 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.
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 int
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.
>>
>
>
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
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?
>
>
> *Bum
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(
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 re
In article <522db8d3.1030...@hastings.org>,
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 n
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.
Wh
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-
>
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., OpenI
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
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
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
> > '
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 poi
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
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
goin
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:
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:m...@hotpy.org>>
wrote:
I would like time to investigate this further, but at the moment I
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 probl
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 a
-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
> a
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
Python-Dev@python.org
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
>
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 +-
>
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
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
>> wo
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
>
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 s
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 improve
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 populatio
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 an
-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 no
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
> m
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
> 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 E
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 o
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
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
f
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
Python-Dev@python.org
https://mail.python.org/mailman/lis
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, e
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 measu
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
45 matches
Mail list logo
