Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

2010-05-19 Thread David Beazley 
> From: "Martin v. L?wis" 
> To: Dj Gilcrease 
> Cc: [email protected]
> Subject: Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
> 
>> I think the new GIL should be given a year or so in the wild before
>> you start trying to optimize theoretical issues you may run into. If
>> in a year people come back and have some examples of where a proper
>> scheduler would help improve speed on multi-core systems even more,
>> then we can address the issue at that time.
> 
> Exactly my feelings.
> 

Although I don't agree that the problem of I/O convoying is merely some 
"theoretical issue", I would agree with a go-slow approach---after all, the new 
GIL hasn't even appeared in any actual release yet.It might be a good idea 
to prominently document the fact that the new GIL has some known performance 
issues (e.g., possible I/O convoying), but that feedback concerning the 
performance of real-world applications is desired.

Cheers,
Dave

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

Re: [Python-Dev] Summing up

2010-05-19 Thread Bill Janssen 
Nick Coghlan  wrote:

> B. some more thought should be given to incorporating the new GIL into
> 2.7. However, this requires two things:
>  - an update to the patch in 7753 to either retain the old GIL for
> platforms not supported by the new GIL or else to make the new GIL a
> configure option
>  - Benjamin accepting that patch (as it would likely mean adding
> another beta release to the cycle)

I think I agree with that, at least for 2.7.0.  My fallback plan is to
write an extension that does the thread affinity hack, monkeypatching
threading.py, only for OS X.  People like me who are really annoyed with
the continued presence of the multicore bug can just add that to site.py
or sitecustomize.py (does that still work?).  I'd like to find out first
whether you can actually change the thread affinity on OS X after the
thread has been started.

> In the absence of an updated version of the 7753 patch, backporting
> the new GIL to 2.7 isn't really a serious option.

Right.  At least, not for this revision level.

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

[Python-Dev] pybuildbot.identify?

2010-05-19 Thread Bill Janssen 
The PPC buildbots are running pretty well, now that I've opened a few
more ports, but I'd like to find this script "pybuildbot.identify" that
they keep complaining about, and install it.  I've poked around the
Python sources, but haven't found it.

Anyone know where to get it from?

Thanks.

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

Re: [Python-Dev] Summing up

2010-05-19 Thread geremy condra 
On Tue, May 18, 2010 at 4:10 PM, Antoine Pitrou  wrote:
> On Tue, 18 May 2010 21:43:30 +0200



> Regardless of the fact that apparently noone reported it in real-world
> conditions, we *could* decide that the issue needs fixing. If we
> decide so, Nir's approach is the most rigorous one: it tries to fix
> the problem thoroughly, rather than graft an additional heuristic. Nir
> also has tested his patch on a variety of machines, more so than Dave
> and I did with our own patches; he is obviously willing to go forward.
>
> Right now, there are two problems with Nir's proposal:
>
> - first, what Nick said: the difficulty of having reliable
>  high-precision cross-platform time sources, which are necessary for
>  the BFS algorithm. Ironically, timestamp counters have their own
>  problems on multi-core machines (they can go out of sync between
>  CPUs). gettimeofday() and clock_gettime() may be precise enough on
>  most Unices, though.
>
> - second, the BFS algorithm is not that well-studied, since AFAIK it
>  was refused for inclusion in the Linux kernel; someone in the
>  python-dev community would therefore have to make sense of, and
>  evaluate, its heuristic.

I don't have the expertise to do this, but I'll be playing with the
patch over the next few weeks, so if there's a specific piece of
data you want, let me know.

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

Re: [Python-Dev] pybuildbot.identify?

2010-05-19 Thread Matthias Klose 

On 19.05.2010 18:09, Bill Janssen wrote:

The PPC buildbots are running pretty well, now that I've opened a few
more ports, but I'd like to find this script "pybuildbot.identify" that
they keep complaining about, and install it.  I've poked around the
Python sources, but haven't found it.

Anyone know where to get it from?


it's just a custom script, currently very linux specific. attached here. maybe 
it's worth to check it in and extend it for other configurations.


  Matthias
#! /bin/sh

for arg in "$@"; do
case "$arg" in
*=*) eval $arg;;
esac
done

echo EXTRATESTOPTS: $EXTRATESTOPTS

echo  system information 
uname -a

if which getconf >/dev/null 2>&1; then
echo
echo "Processors: $(getconf _NPROCESSORS_ONLN)"
fi

if [ -f /proc/meminfo ]; then
cat /proc/meminfo | grep ^Mem
fi

if which df >/dev/null 2>&1; then
echo "Free disk (buildarea): $(df -h . | awk 'NR==2 {print $4}')"
echo "Free disk (/tmp): $(df -h /tmp | awk 'NR==2 {print $4}')"
fi

if which lsb_release >/dev/null 2>&1; then
echo
lsb_release -d -r
fi

if [ -n "$CC" ]; then
echo
$CC --version
fi

# Debian/Ubuntu specific
if which dpkg-architecture >/dev/null 2>&1; then
bds="libc*-dev gcc-?.? binutils"
bds="$bds libreadline*-dev libncurses*-dev tcl*-dev tk*-dev libdb*-dev"
bds="$bds zlib*-dev libgdbm-dev blt-dev libssl-dev libbz*-dev"
bds="$bds libbluetooth-dev libsqlite*-dev libffi*-dev libgpmg1"
dpkg-architecture -a | grep DEB_BUILD_GNU
echo
dpkg -l $bds | grep ^ii
fi

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

Re: [Python-Dev] pybuildbot.identify?

2010-05-19 Thread Martin v. Löwis 
Bill Janssen wrote:
> The PPC buildbots are running pretty well, now that I've opened a few
> more ports, but I'd like to find this script "pybuildbot.identify" that
> they keep complaining about, and install it.  I've poked around the
> Python sources, but haven't found it.

You don't need to bother about it - it's fine that it's missing.

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

Re: [Python-Dev] pybuildbot.identify?

2010-05-19 Thread Bill Janssen 
Matthias Klose  wrote:

> On 19.05.2010 18:09, Bill Janssen wrote:
> > The PPC buildbots are running pretty well, now that I've opened a few
> > more ports, but I'd like to find this script "pybuildbot.identify" that
> > they keep complaining about, and install it.  I've poked around the
> > Python sources, but haven't found it.
> >
> > Anyone know where to get it from?
> 
> it's just a custom script, currently very linux specific. attached
> here. maybe it's worth to check it in and extend it for other
> configurations.
> 
>   Matthias

Well, please check it in somewhere, at least.  Thanks.

Bill

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

Re: [Python-Dev] pybuildbot.identify?

2010-05-19 Thread Martin v. Löwis 
Bill Janssen wrote:
> Matthias Klose  wrote:
> 
>> On 19.05.2010 18:09, Bill Janssen wrote:
>>> The PPC buildbots are running pretty well, now that I've opened a few
>>> more ports, but I'd like to find this script "pybuildbot.identify" that
>>> they keep complaining about, and install it.  I've poked around the
>>> Python sources, but haven't found it.
>>>
>>> Anyone know where to get it from?
>> it's just a custom script, currently very linux specific. attached
>> here. maybe it's worth to check it in and extend it for other
>> configurations.
>>
>>   Matthias
> 
> Well, please check it in somewhere, at least.  Thanks.

Can you please investigate why it was causing an error message in the
first place? The which test should have determined that the script
doesn't exist, and then it shouldn't have been invoked. So I'm puzzled
why there is an error message at all.

I slightly object to checking it in. It's *not* a mandatory part of a
buildbot slave setup, and if you don't know what it is, you don't need
to know.

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

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

2010-05-19 Thread Peter Portante 
Does anybody think that by having problems with the new GIL that it might
further weaken the adoption rate for 3k? -peter


On 5/19/10 7:00 AM, "David Beazley"  wrote:

>> From: "Martin v. L?wis" 
>> To: Dj Gilcrease 
>> Cc: [email protected]
>> Subject: Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>>> I think the new GIL should be given a year or so in the wild before
>>> you start trying to optimize theoretical issues you may run into. If
>>> in a year people come back and have some examples of where a proper
>>> scheduler would help improve speed on multi-core systems even more,
>>> then we can address the issue at that time.
>> 
>> Exactly my feelings.
>> 
> 
> Although I don't agree that the problem of I/O convoying is merely some
> "theoretical issue", I would agree with a go-slow approach---after all, the
> new GIL hasn't even appeared in any actual release yet.It might be a good
> idea to prominently document the fact that the new GIL has some known
> performance issues (e.g., possible I/O convoying), but that feedback
> concerning the performance of real-world applications is desired.
> 
> Cheers,
> Dave
> 
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/peter.a.portante%40gmail.com


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

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

2010-05-19 Thread Martin v. Löwis 
Peter Portante wrote:
> Does anybody think that by having problems with the new GIL that it might
> further weaken the adoption rate for 3k? -peter

No, to the contrary. By having the new GIL being superior to the old
implementation, the adoption rate for 3k will increase.

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

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

2010-05-19 Thread Dj Gilcrease 
On Wed, May 19, 2010 at 4:17 PM, Peter Portante
 wrote:
> Does anybody think that by having problems with the new GIL that it might
> further weaken the adoption rate for 3k? -peter

Nope, because the remaining issues with the new GIL affect the old GIL
as well, and have yet to be proven to affect real world apps. My
server is the only real world example I have seen and the modest 5%
slow down it experiences on the new GIL & multi-core vs new GIL &
single core can potentially be explained by other issues. The old GIL
has a 25 to 30% slowdown on multi vs single core so over all the new
GIL gives my server a 20% speed boost.

Incremental upgrades to core functionality like the GIL is the better
way to go then to try an optimize every facet of it before hand,
because some of those optimizations may have unintended side effects
in real world apps and if you attempt all the optimizations at once it
makes it harder to figure out which is the cause of the unintended
side effects.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

2010-05-19 Thread David Beazley 
Yes, but the million dollar question is whether or not it really is superior 
with the I/O convoying problem in the current implementation (an effect that is 
substantially worse with the new GIL than with the old one by the way).  
Personally, I think the convoying issue is something that will have to be fixed 
eventually.   Although, I also agree that it merits more study--especially with 
real-world applications.

Cheers,
Dave

On May 19, 2010, at 3:34 PM, Martin v. Löwis wrote:

> Peter Portante wrote:
>> Does anybody think that by having problems with the new GIL that it might
>> further weaken the adoption rate for 3k? -peter
> 
> No, to the contrary. By having the new GIL being superior to the old
> implementation, the adoption rate for 3k will increase.
> 
> Regards,
> Martin

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

Re: [Python-Dev] pybuildbot.identify?

2010-05-19 Thread Bill Janssen 
Martin v. Löwis  wrote:

> Bill Janssen wrote:
> > Matthias Klose  wrote:
> > 
> >> On 19.05.2010 18:09, Bill Janssen wrote:
> >>> The PPC buildbots are running pretty well, now that I've opened a few
> >>> more ports, but I'd like to find this script "pybuildbot.identify" that
> >>> they keep complaining about, and install it.  I've poked around the
> >>> Python sources, but haven't found it.
> >>>
> >>> Anyone know where to get it from?
> >> it's just a custom script, currently very linux specific. attached
> >> here. maybe it's worth to check it in and extend it for other
> >> configurations.
> >>
> >>   Matthias
> > 
> > Well, please check it in somewhere, at least.  Thanks.
> 
> Can you please investigate why it was causing an error message in the
> first place? The which test should have determined that the script
> doesn't exist, and then it shouldn't have been invoked. So I'm puzzled
> why there is an error message at all.

I agree.  Must be something in the buildbot code.

> I slightly object to checking it in. It's *not* a mandatory part of a
> buildbot slave setup, and if you don't know what it is, you don't need
> to know.

Well, if it failed silently, I would agree.  As it is, I created a Darwin
version and sent it off to Matthias.

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

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

2010-05-19 Thread Bill Janssen 
Martin v. Löwis  wrote:

> Peter Portante wrote:
> > Does anybody think that by having problems with the new GIL that it might
> > further weaken the adoption rate for 3k? -peter
> 
> No, to the contrary. By having the new GIL being superior to the old
> implementation, the adoption rate for 3k will increase.

Well, if that's a strategy, there's still time to make 2+2 equal 5 in
the "old" implementation.

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

[Python-Dev] Documenting [C]Python's Internals

2010-05-19 Thread Yaniv Aknin 
Hi,

I wanted to let python-dev know about a series of articles about CPython's
internals I'm publishing under the collective title "Guido's Python"* (
http://tech.blog.aknin.name/tag/guidos-python/). Three articles already were
published already, more are planned (mainly focused on CPython/py3k, but
comparisons with other implementations may also be covered; we'll see). So
far I've done an introduction/whirlwind tour of Py_Main and a two-article
in-depth review of the (new-style) object system.

I'm sharing this with you (and hope you care) due to three reasons, probably
in escalating importance:
(a) Maybe some of python-dev's readers would be interested (possibly the
newer and more silent members).

(b) Maybe my scales are wrong, but I was a bit surprised by the number of
readers (>20,000 in the past two weeks); I wouldn't want to mislead such a
reader base and would be happy if a veteran here would be interested in
aiding by technically proofing the material (shan't be too hard I hope, feel
free to contact me directly if qualified and interested).

(c) While the content is currently geared to be blog-oriented, if it's found
worthy by the group I'd be delighted to formulate it into something more
'reference-material-ish' and give it back to the community. I found no
centrally organized CPython-internals material other than bits and pieces
(descrintro, eclectic blog posts, lectures, C-API reference, etc), and I
hope maybe something like this could be featured more officially on
python.org, with the relevant 'this is subject to change' disclaimers (can
be a document for new contributors, for pure Python programmers who're just
interested, or for whatever we decide).

Questions? Comments?
 - Yaniv

* think "Tim Berners-Lee's Web" or "Keanu Reeves' Green Gibberish", see the
first post for details
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Documenting [C]Python's Internals

2010-05-19 Thread Michael Foord 

On 19/05/2010 23:13, Yaniv Aknin wrote:

Hi,

I wanted to let python-dev know about a series of articles about 
CPython's internals I'm publishing under the collective title "Guido's 
Python"* (http://tech.blog.aknin.name/tag/guidos-python/). Three 
articles already were published already, more are planned (mainly 
focused on CPython/py3k, but comparisons with other implementations 
may also be covered; we'll see). So far I've done an 
introduction/whirlwind tour of Py_Main and a two-article in-depth 
review of the (new-style) object system.


Whether or not they become part of the Python documentation I have very 
much enjoyed and appreciated this series of blog entries. I still covet 
the ability to contribute to Python in C and these articles are a great 
introduction to the underlying Python interpreter and object system.


Please continue!

All the best,

Michael Foord



I'm sharing this with you (and hope you care) due to three reasons, 
probably in escalating importance:
(a) Maybe some of python-dev's readers would be interested (possibly 
the newer and more silent members).


(b) Maybe my scales are wrong, but I was a bit surprised by the number 
of readers (>20,000 in the past two weeks); I wouldn't want to mislead 
such a reader base and would be happy if a veteran here would be 
interested in aiding by technically proofing the material (shan't be 
too hard I hope, feel free to contact me directly if qualified and 
interested).


(c) While the content is currently geared to be blog-oriented, if it's 
found worthy by the group I'd be delighted to formulate it into 
something more 'reference-material-ish' and give it back to the 
community. I found no centrally organized CPython-internals material 
other than bits and pieces (descrintro, eclectic blog posts, lectures, 
C-API reference, etc), and I hope maybe something like this could be 
featured more officially on python.org , with the 
relevant 'this is subject to change' disclaimers (can be a document 
for new contributors, for pure Python programmers who're just 
interested, or for whatever we decide).


Questions? Comments?
 - Yaniv

* think "Tim Berners-Lee's Web" or "Keanu Reeves' Green Gibberish", 
see the first post for details



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


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

Re: [Python-Dev] Documenting [C]Python's Internals

2010-05-19 Thread Giampaolo Rodolà 
2010/5/20 Yaniv Aknin :
> Hi,
> I wanted to let python-dev know about a series of articles about CPython's
> internals I'm publishing under the collective title "Guido's Python"*
> (http://tech.blog.aknin.name/tag/guidos-python/). Three articles already
> were published already, more are planned (mainly focused on CPython/py3k,
> but comparisons with other implementations may also be covered; we'll
> see). So far I've done an introduction/whirlwind tour of Py_Main and a
> two-article in-depth review of the (new-style) object system.
> I'm sharing this with you (and hope you care) due to three reasons, probably
> in escalating importance:
> (a) Maybe some of python-dev's readers would be interested (possibly the
> newer and more silent members).
> (b) Maybe my scales are wrong, but I was a bit surprised by the number of
> readers (>20,000 in the past two weeks); I wouldn't want to mislead such a
> reader base and would be happy if a veteran here would be interested in
> aiding by technically proofing the material (shan't be too hard I hope, feel
> free to contact me directly if qualified and interested).
> (c) While the content is currently geared to be blog-oriented, if it's found
> worthy by the group I'd be delighted to formulate it into something more
> 'reference-material-ish' and give it back to the community. I found no
> centrally organized CPython-internals material other than bits and pieces
> (descrintro, eclectic blog posts, lectures, C-API reference, etc), and I
> hope maybe something like this could be featured more officially
> on python.org, with the relevant 'this is subject to change' disclaimers
> (can be a document for new contributors, for pure Python programmers who're
> just interested, or for whatever we decide).
> Questions? Comments?
>  - Yaniv
> * think "Tim Berners-Lee's Web" or "Keanu Reeves' Green Gibberish", see the
> first post for details
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com

Great!
This can be *extremely* useful for new developers like me who still
haven't took a look at cPython internals.
Thanks for the effort.


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method

2010-05-19 Thread Giampaolo Rodolà 
>>> class A:
... def echo(self, x):
... return x
...
>>> a = A()
>>> a.echo()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: echo() takes exactly 2 arguments (1 given)
>>>

I bet my last 2 cents this has already been raised in past but I want
to give it a try and revamp the subject anyway.
Is there a reason why the error shouldn't be adjusted to state that
*1* argument is actually required instead of 2?


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method

2010-05-19 Thread Michael Foord 

On 20/05/2010 00:42, Giampaolo Rodolà wrote:

class A:
 

... def echo(self, x):
... return x
...
   

a = A()
a.echo()
 

Traceback (most recent call last):
   File "", line 1, in
TypeError: echo() takes exactly 2 arguments (1 given)
   
 

I bet my last 2 cents this has already been raised in past but I want
to give it a try and revamp the subject anyway.
Is there a reason why the error shouldn't be adjusted to state that
*1* argument is actually required instead of 2?

   


+1 - I've seen many newbies confused by this error and I sometimes do a 
double-take myself.


All the best,

Michael


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


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

Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method

2010-05-19 Thread John Arbash Meinel 
Giampaolo Rodolà wrote:
 class A:
> ... def echo(self, x):
> ... return x
> ...
 a = A()
 a.echo()
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: echo() takes exactly 2 arguments (1 given)
> 
> I bet my last 2 cents this has already been raised in past but I want
> to give it a try and revamp the subject anyway.
> Is there a reason why the error shouldn't be adjusted to state that
> *1* argument is actually required instead of 2?
> 

Because you wouldn't want to have

A.echo()

Say that it takes 1 argument and (-1 given) ?

John
=:->

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

Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method

2010-05-19 Thread geremy condra 
On Wed, May 19, 2010 at 4:42 PM, Giampaolo Rodolà  wrote:
 class A:
> ...     def echo(self, x):
> ...             return x
> ...
 a = A()
 a.echo()
> Traceback (most recent call last):
>  File "", line 1, in 
> TypeError: echo() takes exactly 2 arguments (1 given)

>
> I bet my last 2 cents this has already been raised in past but I want
> to give it a try and revamp the subject anyway.
> Is there a reason why the error shouldn't be adjusted to state that
> *1* argument is actually required instead of 2?
>
>
> --- Giampaolo

Because it actually does take two arguments (self and x) and it
only got one (self).

I understand the confusion (and was bitten by it myself when I
was a newbie) but the interpreter is only telling you the truth.

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

Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method

2010-05-19 Thread R. David Murray 
On Thu, 20 May 2010 01:42:08 +0200, =?ISO-8859-1?Q?Giampaolo_Rodol=E0?= 
 wrote:
> >>> class A:
> ... def echo(self, x):
> ... return x
> ...
> >>> a = A()
> >>> a.echo()
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: echo() takes exactly 2 arguments (1 given)
> >>>
> 
> I bet my last 2 cents this has already been raised in past but I want
> to give it a try and revamp the subject anyway.
> Is there a reason why the error shouldn't be adjusted to state that
> *1* argument is actually required instead of 2?

You can contribute to issue 2516 if you like :)

http://bugs.python.org/issue2516

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

[Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method

2010-05-19 Thread Stephen J. Turnbull 
Giampaolo Rodolà writes:
 > >>> class A:
 > ... def echo(self, x):
 > ... return x
 > ...
 > >>> a = A()
 > >>> a.echo()
 > Traceback (most recent call last):
 >   File "", line 1, in 
 > TypeError: echo() takes exactly 2 arguments (1 given)
 > >>>
 > 
 > I bet my last 2 cents this has already been raised in past but I want
 > to give it a try and revamp the subject anyway.
 > Is there a reason why the error shouldn't be adjusted to state that
 > *1* argument is actually required instead of 2?

As a function, it does take two arguments, and can be called
explicitly that way, no?  Adjustment is not enough, the message needs
to be substantially rewritten.  Something like

TypeError: invoked as a method, echo() takes exactly 1 argument (0 given)

captures the semantics, but is perhaps too verbose.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Documenting [C]Python's Internals

2010-05-19 Thread Terry Reedy 

On 5/19/2010 6:13 PM, Yaniv Aknin wrote:

Hi,

I wanted to let python-dev know about a series of articles about
CPython's internals I'm publishing under the collective title "Guido's
Python"* (http://tech.blog.aknin.name/tag/guidos-python/).


This link has all post concatenated together in reverse order of how 
they should be read. The tags link returns the same page. Does your blog 
software allow you to make a master post and update with new links as 
available?



 Three

articles already were published already, more are planned (mainly
focused on CPython/py3k, but comparisons with other implementations may
also be covered; we'll see). So far I've done an
introduction/whirlwind tour of Py_Main and a two-article in-depth review
of the (new-style) object system.

I'm sharing this with you (and hope you care) due to three reasons,
probably in escalating importance:
(a) Maybe some of python-dev's readers would be interested (possibly the
newer and more silent members).



(b) Maybe my scales are wrong, but I was a bit surprised by the number
of readers (>20,000 in the past two weeks); I wouldn't want to mislead
such a reader base and would be happy if a veteran here would be
interested in aiding by technically proofing the material (shan't be too
hard I hope, feel free to contact me directly if qualified and interested).


I would if I were qualified, but I an mot. One way to get people to help 
with details is to publish mistakes. This happens all the time on 
python-list ;-). Pre-review would be nice though.



(c) While the content is currently geared to be blog-oriented, if it's
found worthy by the group I'd be delighted to formulate it into
something more 'reference-material-ish' and give it back to the
community. I found no centrally organized CPython-internals material
other than bits and pieces (descrintro, eclectic blog posts, lectures,
C-API reference, etc), and I hope maybe something like this could be
featured more officially on python.org , with the
relevant 'this is subject to change' disclaimers (can be a document for
new contributors, for pure Python programmers who're just interested,
or for whatever we decide).


People have asked for an internals-doc since I started over a decade 
ago. A coherent CPython3.2 Internals would be nice to have with the 3.2 
release next December or so, whether or not it was made 'official'.


Terry Jan Reedy

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