Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Nick Coghlan 
Steve Holden wrote:
> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
> 
 def f(**kwargs):
> ...   kwargs[1] = "dummy"
> ...   print(kwargs)
> ...
 f(this="Guido", that="Raymond", the_other="Steve")
> {'this': 'Guido', 1: 'dummy', 'the_other': 'Steve', 'that': 'Raymond'}
> 
> Or would we? If it's OK to mutate kwargs inside the function to contain
> a non-string key, why isn't it OK to pass a non-string key in?

Because we can easily enough add the kwargs type check to CPython to
improve cross-implementation compatibility, while we can't easily check
individual assignments.

> I understand that it couldn't be generated using keyword argument
> syntax, but I don't see why we discriminate against f(**dict(...)) to
> limit it to what could be generated using keyword argument syntax. Is
> this such a big deal?

The language spec is intended to allow the use of string-only
dictionaries for namespaces. CPython happens to use normal dictionaries
and then optimises them heavily when they only contain string keys, but
other implementations are meant to be allowed to use a separate type
that doesn't permit arbitrary keys.

In cases where it is easy for CPython to check for purely string keys,
that's probably worth doing (especially now it has been noted that the
common case of that check passing can be made fast using the existing
string keys only optimisation tools).

There's also a consistency argument here, in that CPython already
performs this check for Python functions, so it is anomalous that there
are ways to do this without triggering the TypeError.

More exotic namespace abuse is generally harder to detect, and almost
certainly not worth the hassle of flagging on CPython itself (such code
will still fail on implementations that actually use string-key only
namespaces).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Drop OS/2 support?

2010-04-17 Thread Nick Coghlan 
Victor Stinner wrote:
> If we support OS/2, we need a buildbot.

As Andrew said, there are 2 levels of support - the "if we break it,
we'll fix it" level where our buildbots live, and the "we won't go out
of our way to break it, but it may degenerate as other things change (or
simply miss out on some new features)" level.

Eventually there's the "trying not to break this is actively causing
problems, so now we're breaking it on purpose" level of explicitly not
supporting a platform. Relatively recent examples of that were stripping
out the Win9x support, as well as the culling of old code specific to
various proprietary Unix implementions.

I don't know how well this is articulated in the relevant PEP.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Drop OS/2 support?

2010-04-17 Thread Eric Smith 

Andrew MacIntyre wrote:
It is nice to get 
heads-up messages about issues that might involve such support though, 
and it shouldn't take much searching to find me to enquire.


Especially since aimacintyre is listed in Misc/maintainers.rst.

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

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Xavier Morel 
On 16 Apr 2010, at 23:31 , Guido van Rossum wrote:
> 
> +1.
> 
> Apparently dict(x, **y) is going around as "cool hack" for "call
> x.update(y) and return x". Personally I find it more despicable than
> cool.

This description doesn't make sense since `dict(x, **y)` returns not
an updated `x` but a new dictionary merging `x` and `y`.

And that's how (and why) I use it, it's simpler (and — I believe — more
readable) to write `z = dict(x, **y)` than `z = dict(x); z.update(y)`,
since Python doesn't overload addition as it does for lists:
l3 = l1 + l2
works and is equivalent to
l3 = list(l1); l3.extend(l2)

but there is no easy way to say that with dicts, at the moment.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Vinay Sajip 
Steve Holden  holdenweb.com> writes:

> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
> 
> >>> def f(**kwargs):
> ...   kwargs[1] = "dummy"
> ...   print(kwargs)
> ...
> >>> f(this="Guido", that="Raymond", the_other="Steve")
> {'this': 'Guido', 1: 'dummy', 'the_other': 'Steve', 'that': 'Raymond'}

I think that according to the proposal, the above snippet would be OK, but

def f(**kwargs):
kwargs[1] = 'dummy'
g(**kwargs)

would fail at the call of g.

Regards,

Vinay Sajip

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

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Guido van Rossum 
On Fri, Apr 16, 2010 at 4:38 PM, Steve Holden  wrote:
> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>
 def f(**kwargs):
> ...   kwargs[1] = "dummy"
> ...   print(kwargs)
> ...
 f(this="Guido", that="Raymond", the_other="Steve")
> {'this': 'Guido', 1: 'dummy', 'the_other': 'Steve', 'that': 'Raymond'}

>
> Or would we? If it's OK to mutate kwargs inside the function to contain
> a non-string key, why isn't it OK to pass a non-string key in?

Because Python promises that the object the callee sees as 'kwargs' is
"just a dict". But the requirement for what the caller passes in is
different: it must pass in a dict whose keys represent argument names.

If you want an API where you can pass in an arbitrary dict to be
received unchanged, don't use **kw. Remember that the caller can
independently decide whether or not to use the **kw notation -- there
is no implied correspondence between the caller's use of **kw and the
callee's use of it. Note this example:

def f(a, b, **k):
  print(a, b, k)

d = {'a': 1, 'b': 2, 'c': 3}
f(**d)

This will print

1 2 {'c': 3}

Note that the k received by f is not the same as the d passed in! (And
yet d of course is not modified by the operation.)

> I understand that it couldn't be generated using keyword argument
> syntax, but I don't see why we discriminate against f(**dict(...)) to
> limit it to what could be generated using keyword argument syntax. Is
> this such a big deal?

Is portability of code to Jython, IronPython, PyPy a big deal?
According to a slide you recently posted to the PSF board list, it is.

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

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Steve Holden 
Guido van Rossum wrote:
> On Fri, Apr 16, 2010 at 4:38 PM, Steve Holden  wrote:
>> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>>
> def f(**kwargs):
>> ...   kwargs[1] = "dummy"
>> ...   print(kwargs)
>> ...
> f(this="Guido", that="Raymond", the_other="Steve")
>> {'this': 'Guido', 1: 'dummy', 'the_other': 'Steve', 'that': 'Raymond'}
>> Or would we? If it's OK to mutate kwargs inside the function to contain
>> a non-string key, why isn't it OK to pass a non-string key in?
> 
> Because Python promises that the object the callee sees as 'kwargs' is
> "just a dict". But the requirement for what the caller passes in is
> different: it must pass in a dict whose keys represent argument names.
> 
> If you want an API where you can pass in an arbitrary dict to be
> received unchanged, don't use **kw. Remember that the caller can
> independently decide whether or not to use the **kw notation -- there
> is no implied correspondence between the caller's use of **kw and the
> callee's use of it. Note this example:
> 
> def f(a, b, **k):
>   print(a, b, k)
> 
> d = {'a': 1, 'b': 2, 'c': 3}
> f(**d)
> 
> This will print
> 
> 1 2 {'c': 3}
> 
> Note that the k received by f is not the same as the d passed in! (And
> yet d of course is not modified by the operation.)
> 
Good point, and one I hadn't thought of. I was blithely assuming that
the dict seen by the called function was always what was passed as the
dict argument.

>> I understand that it couldn't be generated using keyword argument
>> syntax, but I don't see why we discriminate against f(**dict(...)) to
>> limit it to what could be generated using keyword argument syntax. Is
>> this such a big deal?
> 
> Is portability of code to Jython, IronPython, PyPy a big deal?
> According to a slide you recently posted to the PSF board list, it is.
> 
And I haven't changed my mind since. Thanks for the comprehensive response.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Guido van Rossum 
On Sat, Apr 17, 2010 at 5:41 AM, Vinay Sajip  wrote:
> Steve Holden  holdenweb.com> writes:
>
>> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>>
>> >>> def f(**kwargs):
>> ...   kwargs[1] = "dummy"
>> ...   print(kwargs)
>> ...
>> >>> f(this="Guido", that="Raymond", the_other="Steve")
>> {'this': 'Guido', 1: 'dummy', 'the_other': 'Steve', 'that': 'Raymond'}
>
> I think that according to the proposal, the above snippet would be OK, but
>
> def f(**kwargs):
>    kwargs[1] = 'dummy'
>    g(**kwargs)
>
> would fail at the call of g.

And that is already the status quo. Try it out in your friendly Python
interpreter.

The *only* thing that should be *changed* is for the dict() builtin to
insist that if it receives a dict containing keyword arguments the
keys must all be strings. This *only* affects the dict() builtin. It
has keyword arguments so that instead of {'foo': 1, 'bar': 2} you can
write dict(foo=1, bar=2), which arguably is more readable because it
doesn't have so many quotes. OTOH calling dict(x, **y) is a weird
hack. Note that if you wrote a wrapper function in Python around
dict() with the same behavior there would be no way to prevent the
check that all the keys are strings.

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

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Nick Coghlan 
Guido van Rossum wrote:
> Because Python promises that the object the callee sees as 'kwargs' is
> "just a dict".

Huh, I thought kwargs was allowed to be implemented as a
string-keys-only dict (similar to class and module namespaces) while
still be a valid Python implementation. I guess I was wrong.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Guido van Rossum 
On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan  wrote:
> Guido van Rossum wrote:
>> Because Python promises that the object the callee sees as 'kwargs' is
>> "just a dict".
>
> Huh, I thought kwargs was allowed to be implemented as a
> string-keys-only dict (similar to class and module namespaces) while
> still be a valid Python implementation. I guess I was wrong.

Actually I don't know about that. Is there language anywhere in the
language reference that says this? What do IronPython, Jython, PyPy
actually do?

In any case my line of reasoning in this case isn't affected by this;
as I pointed out in my reply to Steve, the relation between the **k
passed in by the caller and the **k received by the callee is less
direct than you might think. The proposed change *only* affects the
dict() builtin; any change in the type of **k seen by the callee would
potentially affect all user-defined functions.

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

[Python-Dev] http://bugs.python.org/ is down

2010-04-17 Thread Victor Stinner 
Hi,

http://bugs.python.org/ displays "Service Temporarily Unavailable". Is it 
normal?

-- 
Victor Stinner
http://www.haypocalc.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] http://bugs.python.org/ is down

2010-04-17 Thread Daniel Stutzbach 
On Sat, Apr 17, 2010 at 12:17 PM, Victor Stinner <
victor.stin...@haypocalc.com> wrote:

> http://bugs.python.org/ displays "Service Temporarily Unavailable". Is it
> normal?
>

It's working fine for me.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Benjamin Peterson 
2010/4/17 Guido van Rossum :
> On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan  wrote:
>> Guido van Rossum wrote:
>>> Because Python promises that the object the callee sees as 'kwargs' is
>>> "just a dict".
>>
>> Huh, I thought kwargs was allowed to be implemented as a
>> string-keys-only dict (similar to class and module namespaces) while
>> still be a valid Python implementation. I guess I was wrong.
>
> Actually I don't know about that. Is there language anywhere in the
> language reference that says this? What do IronPython, Jython, PyPy
> actually do?

Similar to CPython, PyPy has dict versions optimized for strings,
which fall back to the general version when given non-string keys.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Dino Viehland 
Benjamin wrote:
> 2010/4/17 Guido van Rossum :
> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan 
> wrote:
> >> Guido van Rossum wrote:
> >>> Because Python promises that the object the callee sees as 'kwargs'
> is
> >>> "just a dict".
> >>
> >> Huh, I thought kwargs was allowed to be implemented as a
> >> string-keys-only dict (similar to class and module namespaces) while
> >> still be a valid Python implementation. I guess I was wrong.
> >
> > Actually I don't know about that. Is there language anywhere in the
> > language reference that says this? What do IronPython, Jython, PyPy
> > actually do?
> 
> Similar to CPython, PyPy has dict versions optimized for strings,
> which fall back to the general version when given non-string keys.

IronPython as well.  The only place we use a string only dict is for
new-style classes whose dict's are wrapped in a dictproxy.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Maciej Fijalkowski 
On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland  wrote:
> Benjamin wrote:
>> 2010/4/17 Guido van Rossum :
>> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan 
>> wrote:
>> >> Guido van Rossum wrote:
>> >>> Because Python promises that the object the callee sees as 'kwargs'
>> is
>> >>> "just a dict".
>> >>
>> >> Huh, I thought kwargs was allowed to be implemented as a
>> >> string-keys-only dict (similar to class and module namespaces) while
>> >> still be a valid Python implementation. I guess I was wrong.
>> >
>> > Actually I don't know about that. Is there language anywhere in the
>> > language reference that says this? What do IronPython, Jython, PyPy
>> > actually do?
>>
>> Similar to CPython, PyPy has dict versions optimized for strings,
>> which fall back to the general version when given non-string keys.
>
> IronPython as well.  The only place we use a string only dict is for
> new-style classes whose dict's are wrapped in a dictproxy.

And yet that breaks some code :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS information, tags

2010-04-17 Thread anatoly techtonik 
On Fri, Apr 16, 2010 at 7:13 AM, Steve Holden  wrote:
> Brian Curtin wrote:
>> On Thu, Apr 15, 2010 at 03:20, anatoly techtonik > > wrote:
>>
>>     On Tue, Apr 13, 2010 at 3:54 PM, Nick Coghlan >     > wrote:
>>     >
>>     >>>            I am surprised to see that the bug-tracker
>>     >>> doesn't have an OS classifier or ability to add
>>     >>> tags ? Since a number of issues reported seem to
>>
>>     Just to remind about my +1 for user editable tags.
>>
>>
>> -sys.maxint on just about anything user editable except for the title or
>> messages on an issue. I don't think user editable tags on an issue bring
>> anything to the table except making it seem more "web 2.0". Searching
>> user-generated tags would be a nightmare because you'd have to know
>> every combination of some idea in order to get relevant results (e.g.,
>> windows, windoze, window$, win32).
>>
>
> Yes, tight vocabulary control will lead to more consistent classifications.

There can be an interface to normalize tags. Known synonyms can be
merged to the primary list automatically warning user about
substitution. If word is not in primary list the user may propose to
add it to main list. Tags with most user proposals will clearly
indicate candidates for inclusion.

Users still should be able to tag issues with primary set of tags or
propose a tag for an issue.
This will partially take triaging burden off the core developers and
will help to spot people with most proposals as potential contributors
who deserve more tracker privileges.

We need tags gameplay to get people addicted.
-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Dino Viehland 
Maciej wrote:
> On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland 
> wrote:
> > Benjamin wrote:
> >> 2010/4/17 Guido van Rossum :
> >> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan 
> >> wrote:
> >> >> Guido van Rossum wrote:
> >> >>> Because Python promises that the object the callee sees as
> 'kwargs'
> >> is
> >> >>> "just a dict".
> >> >>
> >> >> Huh, I thought kwargs was allowed to be implemented as a
> >> >> string-keys-only dict (similar to class and module namespaces)
> while
> >> >> still be a valid Python implementation. I guess I was wrong.
> >> >
> >> > Actually I don't know about that. Is there language anywhere in
> the
> >> > language reference that says this? What do IronPython, Jython,
> PyPy
> >> > actually do?
> >>
> >> Similar to CPython, PyPy has dict versions optimized for strings,
> >> which fall back to the general version when given non-string keys.
> >
> > IronPython as well.  The only place we use a string only dict is for
> > new-style classes whose dict's are wrapped in a dictproxy.
> 
> And yet that breaks some code :-)

Sure, if you do:

class C(object):
locals()[object()] = 42

dir(C)

You lose.  Once I'm aware of some piece of code in the wild doing this
then I'll be happy to change IronPython to be more compatible. :)


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

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Maciej Fijalkowski 
On Sat, Apr 17, 2010 at 12:03 PM, Dino Viehland  wrote:
> Maciej wrote:
>> On Sat, Apr 17, 2010 at 11:38 AM, Dino Viehland 
>> wrote:
>> > Benjamin wrote:
>> >> 2010/4/17 Guido van Rossum :
>> >> > On Sat, Apr 17, 2010 at 9:22 AM, Nick Coghlan 
>> >> wrote:
>> >> >> Guido van Rossum wrote:
>> >> >>> Because Python promises that the object the callee sees as
>> 'kwargs'
>> >> is
>> >> >>> "just a dict".
>> >> >>
>> >> >> Huh, I thought kwargs was allowed to be implemented as a
>> >> >> string-keys-only dict (similar to class and module namespaces)
>> while
>> >> >> still be a valid Python implementation. I guess I was wrong.
>> >> >
>> >> > Actually I don't know about that. Is there language anywhere in
>> the
>> >> > language reference that says this? What do IronPython, Jython,
>> PyPy
>> >> > actually do?
>> >>
>> >> Similar to CPython, PyPy has dict versions optimized for strings,
>> >> which fall back to the general version when given non-string keys.
>> >
>> > IronPython as well.  The only place we use a string only dict is for
>> > new-style classes whose dict's are wrapped in a dictproxy.
>>
>> And yet that breaks some code :-)
>
> Sure, if you do:
>
> class C(object):
>    locals()[object()] = 42
>
> dir(C)
>
> You lose.  Once I'm aware of some piece of code in the wild doing this
> then I'll be happy to change IronPython to be more compatible. :)
>

There was one thing in sqlalchemy tests, not sure exactly why. There
were also other things that I've seen, but consequently it was decided
that it's only accidentally working on CPython and namespace should
contain string-only keys.

Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] http://bugs.python.org/ is down

2010-04-17 Thread aditya bhargava 
Works for me too.

On Sat, Apr 17, 2010 at 12:19 PM, Daniel Stutzbach <
dan...@stutzbachenterprises.com> wrote:

> On Sat, Apr 17, 2010 at 12:17 PM, Victor Stinner <
> victor.stin...@haypocalc.com> wrote:
>
>> http://bugs.python.org/ displays "Service Temporarily Unavailable". Is it
>> normal?
>>
>
> It's working fine for me.
> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC 
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/bluemangroupie%40gmail.com
>
>


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

[Python-Dev] bbreport

2010-04-17 Thread Victor Stinner 
Hi,

Ezio and Florent are developing a tool called bbreport to collect buildbot 
results and generate short reports to the command line. It's possible to 
filter results by Python branch, builder name, etc. I send patches to link 
failed tests to existing issues to see quickly known failures vs new failures. 
This tool becomes really useful to analyze buildbot results!

http://code.google.com/p/bbreport/

bbreport requires Python trunk (2.7) and color output only works on UNIX/BSD 
OS (ie. not Windows).

-- 
Victor Stinner
http://www.haypocalc.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Steve Holden 
Dino Viehland wrote:
> Maciej wrote:
[...]
>> And yet that breaks some code :-)
> 
> Sure, if you do:
> 
> class C(object):
> locals()[object()] = 42
> 
> dir(C)
> 
> You lose.  Once I'm aware of some piece of code in the wild doing this
> then I'll be happy to change IronPython to be more compatible. :)
> 
> 
This would be a lose anyway, since the CPython specifications suggest
that you should not rely on being able to change locals() (or at least
shouldn't expect that such changes are actually reflected in the local
namespace).

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bbreport

2010-04-17 Thread Mark Dickinson 
On Sat, Apr 17, 2010 at 7:41 PM, Victor Stinner
 wrote:
> Ezio and Florent are developing a tool called bbreport to collect buildbot
> results and generate short reports to the command line. It's possible to
> filter results by Python branch, builder name, etc. I send patches to link
> failed tests to existing issues to see quickly known failures vs new failures.
> This tool becomes really useful to analyze buildbot results!

Seconded.  I've been using this for a few days, and found it
especially useful to be able to get a quick summary of exactly *which*
tests are failing on the various buildbots.

> bbreport requires Python trunk (2.7) and color output only works on UNIX/BSD
> OS (ie. not Windows).

Does it really need trunk?  I've been running it under 2.6 without
problems, but I probably haven't explored all the options fully.

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

Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

2010-04-17 Thread David Bolen 
"Martin v. Löwis"  writes:

>  This actually happened on Windows - some people now
> recommend to run the buildbot scripts on a regular developer checkout,
> because they supposedly do the right things.

I have to admit that I'm guilty of this (though to be fair most of my
test builds are buildbot-related), if only because it takes care of
all the external stuff automatically and self-contained in the build
tree.

> I would rather prefer to have the buildbot run the same commands that we
> recommend developers to run. The knowledge about these should be in the
> README, and it should be stable knowledge, i.e. require infrequent
> changes. This is true for Unix: configure/make/make test/make clean
> had been the correct procedure for ten years now. The Unix buildbot only
> deviates slightly, to have the slaves run a more expensive version of
> the test suite.

In digging around a bit, it would appear that there's actually quite a
bit of OSX support already in the Makefile (either the main one or
the one in Mac).  There's even a target that tests both halves of a
universal build (using rosetta for the PPC version) on an Intel box.

I suspect it's just a question of setting up a Mac-appropriate
builder, using the universal SDK in the configure step, and whatever
Makefile targets are deemed best and current, perhaps with the
addition of support for pulling in the third party stuff through
externals or whatever.  A first pass could just be to factor that
process into a separate stage of build-installer that could be run
independently of the rest of the installer build process.

In the interim, I've generated the third-party libraries via the
current trunk build-installer script and installed them in /usr/local
on my buildbot, so they are found by any of the buildbot builds using
the stock configure/make approach.  Other than a slight update to the
bzip version, looks like the dependency versions in the installer
script haven't changed for over a year, so I suspect the libraries are
fine for any of the branches currently being built.

I also updated to the latest 8.4.19 Tcl/Tk in /Library/Frameworks
since I saw some interpreter crashes in tests in what appeared to be a
Tcl code path.  It had been building against my system 8.4.7 Tcl.  The
Windows buildbot uses Tcl 8.5 - not sure if that should be preferred
for the Mac buildbot as well, but will leave it at 8.4 for now.

I think this should create test builds more representative of the
final binaries.  It's not testing a universal framework build, but the
test target only tests the Intel path anyway, the generated code
should still be the same, and the same libraries are in use.

If anyone more familiar with this side of things for OSX has some
spare time down the road, I'd be happy to help work on improving the
process for the buildbot.

> I'd be interested in setting up daily builds then. For these, I think
> it's fine that they may differ slightly from the official binaries -
> people would recognize that they are testing a different set of binaries.

We can certainly start by just trying to automate the execution of
build-installer, something I suspect can be completely controlled from
the master side, and then uploading the resulting dmg file.  I'd be
happy to help coordinate any experiments offline if you're interested.

I do currently have a DMG built for 2.7 Beta 1, if it would be useful.

-- David

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

Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

2010-04-17 Thread Steve Holden 
David Bolen wrote:
> "Martin v. Löwis"  writes:
> 
>>  This actually happened on Windows - some people now
>> recommend to run the buildbot scripts on a regular developer checkout,
>> because they supposedly do the right things.
> 
> I have to admit that I'm guilty of this (though to be fair most of my
> test builds are buildbot-related), if only because it takes care of
> all the external stuff automatically and self-contained in the build
> tree.
> 
>> I would rather prefer to have the buildbot run the same commands that we
>> recommend developers to run. The knowledge about these should be in the
>> README, and it should be stable knowledge, i.e. require infrequent
>> changes. This is true for Unix: configure/make/make test/make clean
>> had been the correct procedure for ten years now. The Unix buildbot only
>> deviates slightly, to have the slaves run a more expensive version of
>> the test suite.
> 
> In digging around a bit, it would appear that there's actually quite a
> bit of OSX support already in the Makefile (either the main one or
> the one in Mac).  There's even a target that tests both halves of a
> universal build (using rosetta for the PPC version) on an Intel box.
> 
> I suspect it's just a question of setting up a Mac-appropriate
> builder, using the universal SDK in the configure step, and whatever
> Makefile targets are deemed best and current, perhaps with the
> addition of support for pulling in the third party stuff through
> externals or whatever.  A first pass could just be to factor that
> process into a separate stage of build-installer that could be run
> independently of the rest of the installer build process.
> 
> In the interim, I've generated the third-party libraries via the
> current trunk build-installer script and installed them in /usr/local
> on my buildbot, so they are found by any of the buildbot builds using
> the stock configure/make approach.  Other than a slight update to the
> bzip version, looks like the dependency versions in the installer
> script haven't changed for over a year, so I suspect the libraries are
> fine for any of the branches currently being built.
> 
> I also updated to the latest 8.4.19 Tcl/Tk in /Library/Frameworks
> since I saw some interpreter crashes in tests in what appeared to be a
> Tcl code path.  It had been building against my system 8.4.7 Tcl.  The
> Windows buildbot uses Tcl 8.5 - not sure if that should be preferred
> for the Mac buildbot as well, but will leave it at 8.4 for now.
> 
> I think this should create test builds more representative of the
> final binaries.  It's not testing a universal framework build, but the
> test target only tests the Intel path anyway, the generated code
> should still be the same, and the same libraries are in use.
> 
> If anyone more familiar with this side of things for OSX has some
> spare time down the road, I'd be happy to help work on improving the
> process for the buildbot.
> 
>> I'd be interested in setting up daily builds then. For these, I think
>> it's fine that they may differ slightly from the official binaries -
>> people would recognize that they are testing a different set of binaries.
> 
> We can certainly start by just trying to automate the execution of
> build-installer, something I suspect can be completely controlled from
> the master side, and then uploading the resulting dmg file.  I'd be
> happy to help coordinate any experiments offline if you're interested.
> 
> I do currently have a DMG built for 2.7 Beta 1, if it would be useful.
> 
Great work David, this is a terrific step forward. Thanks!

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

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

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Maciej Fijalkowski 
On Sat, Apr 17, 2010 at 1:03 PM, Steve Holden  wrote:
> Dino Viehland wrote:
>> Maciej wrote:
> [...]
>>> And yet that breaks some code :-)
>>
>> Sure, if you do:
>>
>> class C(object):
>>     locals()[object()] = 42
>>
>> dir(C)
>>
>> You lose.  Once I'm aware of some piece of code in the wild doing this
>> then I'll be happy to change IronPython to be more compatible. :)
>>
>>
> This would be a lose anyway, since the CPython specifications suggest
> that you should not rely on being able to change locals() (or at least
> shouldn't expect that such changes are actually reflected in the local
> namespace).

You can override __new__ of a type subclass to achieve the same effect
(or even directly call type.__new__ with strange dict as an argument).

Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very Strange Argument Handling Behavior

2010-04-17 Thread Steven D'Aprano 
On Sun, 18 Apr 2010 07:47:08 am Maciej Fijalkowski wrote:
> On Sat, Apr 17, 2010 at 1:03 PM, Steve Holden  
wrote:
> > Dino Viehland wrote:
> >> Maciej wrote:
> >
> > [...]
> >
> >>> And yet that breaks some code :-)
> >>
> >> Sure, if you do:
> >>
> >> class C(object):
> >>     locals()[object()] = 42
> >>
> >> dir(C)
> >>
> >> You lose.  Once I'm aware of some piece of code in the wild doing
> >> this then I'll be happy to change IronPython to be more
> >> compatible. :)
> >
> > This would be a lose anyway, since the CPython specifications
> > suggest that you should not rely on being able to change locals()
> > (or at least shouldn't expect that such changes are actually
> > reflected in the local namespace).
>
> You can override __new__ of a type subclass to achieve the same
> effect (or even directly call type.__new__ with strange dict as an
> argument).

I think that only works in Python 3.x, in 2.x the __dict__ is always a 
regular dict no matter what you pass. At least for CPython. If there is 
a way to set the dict of a class to something other than a regular dict 
in CPython 2.x, I would be very pleased!



-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com