On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray wrote:
> When the removal was being pondered, the possibility of keeping certain
> bits that were more ready than others was discussed. Perhaps the best
> way forward is to put it back in bits, with the most finished (and PEP
> relevant) stuff goin
On Wed, 12 Sep 2012 18:07:42 -0400, Brett Cannon wrote:
> On Wed, Sep 12, 2012 at 3:28 PM, Lennart Regebro wrote:
>
> > On Wed, Sep 12, 2012 at 9:02 PM, Ãric Araujo wrote:
> > > âfind a PEP dictator and propose changesâ. And when I started the
> > > thread about removing packaging in 3.3,
On Wed, Sep 12, 2012 at 3:28 PM, Lennart Regebro wrote:
> On Wed, Sep 12, 2012 at 9:02 PM, Éric Araujo wrote:
> > “find a PEP dictator and propose changes”. And when I started the
> > thread about removing packaging in 3.3, hundreds of replies discussed
> > changing the whole distutils architec
> I'm happy to note that as of version 0.6.28 distutils (the setuptools
> fork)
You certainly mean distribute. :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
On Wed, Sep 12, 2012 at 3:28 PM, Lennart Regebro wrote:
> On Wed, Sep 12, 2012 at 9:02 PM, Éric Araujo wrote:
>> “find a PEP dictator and propose changes”. And when I started the
>> thread about removing packaging in 3.3, hundreds of replies discussed
>> changing the whole distutils architecture
On Wed, Sep 12, 2012 at 9:02 PM, Éric Araujo wrote:
> “find a PEP dictator and propose changes”. And when I started the
> thread about removing packaging in 3.3, hundreds of replies discussed
> changing the whole distutils architecture, splitting the project,
> exploring new systems, etc.,
Yes,
On Thu, Sep 13, 2012 at 7:02 AM, Éric Araujo wrote:
> Hi,
>
> Lib/packaging is in the repository history, and in my backup clones, but
> it’s not visible in any branch head as we have no branch for 3.4 yet. I
> can bring the directory back with a simple Mercurial command.
>
> However, it’s not cl
On Wed, 12 Sep 2012 15:02:42 -0400
Éric Araujo wrote:
> Hi,
>
> Lib/packaging is in the repository history, and in my backup clones, but
> it’s not visible in any branch head as we have no branch for 3.4 yet. I
> can bring the directory back with a simple Mercurial command.
>
> However, it’s no
Hi,
Lib/packaging is in the repository history, and in my backup clones, but
it’s not visible in any branch head as we have no branch for 3.4 yet. I
can bring the directory back with a simple Mercurial command.
However, it’s not clear to me that we want to do that. At the inception
of the proje
Christian Heimes wrote:
> Am 12.09.2012 16:22, schrieb Stefan Krah:
> > This is a false positive:
>
> You might be right. But did you notice that there is much more code
> beyond the large comment block in PyLong_FromString()? There might be
> other code paths that push str beyond its limit.
Yes
On 9/12/2012 3:36 AM, Serhiy Storchaka wrote:
I personally would prefer a 2to3-like "modernizer" (as a separate
utility and as plugins for the IDEs), which would have found some
templates and offered replacing by a more modern, readable (and possibly
effective) variant. The decision on the appli
Am 12.09.2012 18:14, schrieb Terry Reedy:
> On 9/12/2012 10:22 AM, Stefan Krah wrote:
>> christian.heimes wrote:
>>> Fix out of bounds read in long_new() for empty bytes with an explicit
>>> base.
>>> int(b'', somebase) calls PyLong_FromString() with char* of length 1
>
> I don't know what happen
On 9/12/2012 10:22 AM, Stefan Krah wrote:
christian.heimes wrote:
Fix out of bounds read in long_new() for empty bytes with an explicit base.
>> int(b'', somebase) calls PyLong_FromString() with char* of length 1
I don't know what happens internally, but such calls raise
ValueError: invalid l
Am 12.09.2012 17:42, schrieb Stefan Krah:
> I think 'k' is owned by the PySTEntryObject after it is assigned here:
>
> ste->ste_id = k;
>
>
> So ste_dealloc() will call Py_XDECREF(k) a second time.
You are right. I missed that ste steals the reference to k and does its
own cleanup. I've fixed t
christian.heimes wrote:
> summary:
> Closed reference leak of variable 'k' in function ste_new which wasn't
> decrefed in error cases
>
> files:
> Python/symtable.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>
> diff --git a/Python/symtable.c b/Python/symtable.c
> ---
Am 12.09.2012 16:22, schrieb Stefan Krah:
> This is a false positive:
>
>
>
> Assumption: string ==
christian.heimes wrote:
> Make sure that *really* no more than sizeof(ifr.ifr_name) chars are
> strcpy-ed to ifr.ifr_name and that the string is *always* NUL terminated. New
> code shouldn't use strcpy(), too. CID 719692
>
> files:
> Modules/socketmodule.c | 3 ++-
> 1 files changed, 2 in
christian.heimes wrote:
> Fix out of bounds read in long_new() for empty bytes with an explicit base.
> int(b'', somebase) calls PyLong_FromString() with char* of length 1 but the
> function accesses the first argument at offset 1. CID 715359
>
> files:
> Objects/longobject.c | 4 ++--
>
On Sep 11, 2012, at 09:30 PM, Chris Jerdonek wrote:
>I didn't have time to respond Barry's e-mail from four hours ago
>before this was committed. I think this change may be problematic.
>At the least, I think people should have an opportunity to air their
>specific concerns and talk through the i
On Tue, Sep 11, 2012 at 2:57 PM, Nick Coghlan wrote:
> On Tue, Sep 11, 2012 at 8:41 PM, Victor Stinner
> wrote:
>> * Call builtin functions if arguments are constants. Examples:
>>
>> - len("abc") => 3
>> - ord("A") => 65
>
> This is fine in an external project, but should never be added to t
On Sep 11, 2012, at 6:32 AM, Christian Heimes wrote:
>
> maybe you have noticed a bunch of commits I made the last couple of
> days.
I noticed! Thank you for all the work to improve quality.
Raymond___
Python-Dev mailing list
Python-Dev@python.org
>> Projects using the same code base for Python 2 and Python 3 contain a
>> lot of inefficient code. For example, using the six library, a simple
>> Unicode literal strings becomes a function code: u('unicode').
>
> But are you able to do enough static analysis to feel comfortable that
> this is th
2012/9/12 Serhiy Storchaka :
>>> set([x for ...]) => {x for ...}
>>> dict([(k, v) for ...]) => {k: v for ...}
>>> dict((k, v) for ...) => {k: v for ...}
>>> ''.join([s for ...]) => ''.join(s for ...)
>>> a.extend([s for ...]) => a.extend(s for ...)
>>
>> These optimizations look correct.
>
> Actual
On 12.09.12 00:47, Victor Stinner wrote:
x = x + [y] => x.append(y)
x = x + [y, z] => x.extend([y, z])
It behaves differently if x is not a list, but str for example.
Actually even worse. Transformations applicable only if x has not
aliases. Pseudocode:
if type(x) is list and refcount(x)
Hello
I was wondering if anyone knows if the removed Lib/packaging directory
landed in some other places after it was removed.
We have http://hg.python.org/distutils2 be the 'packaging' version is a
full py3-renamed version we need to keep mirrored
Cheers
Tarek
_
On 12.09.12 00:47, Victor Stinner wrote:
set([x for ...]) => {x for ...}
dict([(k, v) for ...]) => {k: v for ...}
dict((k, v) for ...) => {k: v for ...}
''.join([s for ...]) => ''.join(s for ...)
a.extend([s for ...]) => a.extend(s for ...)
These optimizations look correct.
Actually generator
26 matches
Mail list logo
