On Wed, Feb 18, 2009 at 6:38 PM, wrote:
> On Wed, 18 Feb 2009 at 21:25, Antoine Pitrou wrote:
>>
>> Nick Coghlan gmail.com> writes:
>>>
>>> I *think* the 2.x system had an internal buffer that was used by the
>>> file iterator, but not by the file methods. With the new IO stack for
>>> 3.0, ther
On Wed, 18 Feb 2009 at 21:25, Antoine Pitrou wrote:
Nick Coghlan gmail.com> writes:
I *think* the 2.x system had an internal buffer that was used by the
file iterator, but not by the file methods. With the new IO stack for
3.0, there is now a common buffer shared by all the file operations
(in
Hi there,
this is just a little note / reminder to try to submit Roundup patches
and enhancements that you may have accumulated while working on the
bugs.python.org tracker.
A couple of weeks ago I moved the Roundup project's own tracker close to
where bugs.python.org is hosted, and am now act
Someone has implemented a version of dir() which is much nicer for
human consumption. The difference is striking enough that I thought
it would be bringing to python-dev's attention.
http://github.com/inky/see/tree/master
>>> pencil_case = []
>>> dir(pencil_case)
['__add__', '__class__', '_
Christian Heimes wrote:
In 2.x a class objects wrap their functions in a method wrapper. The
method wrapper does the type check. You can get around the type check by
using the im_func attribute of the method wrapper.
You could probably also create a decorator that
gives you something behaving
Sebastian Rittau wrote:
Is it a design decision that duck-typing self does not work or is there a
technical reason?
There's no technical reason as far as user-defined
classes are concerned. I think it was introduced to
help catch errors due to making inherited method
calls to the wrong class,
Steven Bethard wrote:
>> Is it a design decision that duck-typing self does not work or is there a
>> technical reason? From a practical standpoint it seems that being able to
>> duck-type self has merit, for example in unit testing complex classes.
>
> Works for me in 3.0:
It works in 3.0 becaus
On Wed, Feb 18, 2009 at 2:32 PM, Sebastian Rittau
wrote:
> Hi!
>
> I am curious why the following will not work in Python:
>
> class foo(object):
> def bar(self):
> print self.attr
>
> class duck(object):
> attr = 3.14
>
> foo.bar(duck())
>
> Is it a design decision that duck
Hi!
I am curious why the following will not work in Python:
class foo(object):
def bar(self):
print self.attr
class duck(object):
attr = 3.14
foo.bar(duck())
Is it a design decision that duck-typing self does not work or is there a
technical reason? From
Hi Venkatraman,
Venkatraman S wrote:
>
> On Tue, Feb 17, 2009 at 1:45 PM, "Martin v. Löwis" wrote:
>>
>> Don't expect too much
>> help from other people - I have been waiting for volunteers to show up
>> helping with the tracker for more than a year now.
>
> I have been mostly a silent spectator
> Let me know if this is not wanted. I can drop it it's no big deal.
That is fine with me. I was worried that you might have made
Lib/distutils external, which I would not have liked.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
htt
2009/2/18 "Martin v. Löwis" :
>> this will use externals, (see
>> http://svn.python.org/projects/distutils/trunk/)
>
> This I don't understand. There is file named EXTERNALS.txt, but I don't
> understand its purpose.
This is how I work with externals. This file is used to store the
svn:external
> this will use externals, (see
> http://svn.python.org/projects/distutils/trunk/)
This I don't understand. There is file named EXTERNALS.txt, but I don't
understand its purpose.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:
> I have been mostly a silent spectator around and would like to chip in.
> Need some initial throttle(help) for the full-fledged attack :)
Please take a look at the meta tracker. It has various open issues, many
open for many months now. Please tackle one that can be fixed through
patches to the
Mitchell L Model wrote:
In Digest Vol. 67, Issue 52 (13 Feb 2009) I pointed out that Python 2's
prohibition against performing readlines on a file being iterated over
appears to have been lifted in Python 3. I asked if this was intentional
and whether it should be add to the "What's New" docume
Hello,
Nick Coghlan gmail.com> writes:
>
> I *think* the 2.x system had an internal buffer that was used by the
> file iterator, but not by the file methods. With the new IO stack for
> 3.0, there is now a common buffer shared by all the file operations
> (including iteration).
>
> However, gi
Mitchell L Model wrote:
> I didn't get any response. Is this the wrong list for the question? Did
> appropriate responders assume another would respond?
Probably the latter (I know I left it to those that had more to do with
the IO stack rewrite). This is definitely the right list for the question
Le Wednesday 18 February 2009 20:48:17 Benjamin Peterson, vous avez écrit :
> On Wed, Feb 18, 2009 at 9:30 AM, Guido van Rossum wrote:
> > This prompts a wild idea -- perhaps the framework of 2to3 could be
> > reused to create a new linter?
>
> The 2to3 syntax tree is probably two low-level for th
On Wed, Feb 18, 2009 at 9:30 AM, Guido van Rossum wrote:
> This prompts a wild idea -- perhaps the framework of 2to3 could be
> reused to create a new linter?
The 2to3 syntax tree is probably two low-level for that. It's good for
simple isolated transformations like print, but not so much for the
On Wed, Feb 18, 2009 at 12:42 PM, Mitchell L Model wrote:
> I'd appreciate comments -- especially a redirection to a different list, if
> this one isn't appropriate for my query.
It seems as though you have the right list, but perhaps whoever knows
about the change is busy, or maybe several peopl
In Digest Vol. 67, Issue 52 (13 Feb 2009) I pointed out that Python
2's prohibition against performing readlines on a file being iterated
over appears to have been lifted in Python 3. I asked if this was
intentional and whether it should be add to the "What's New"
documentation. I also express
2009/2/17 Georg Brandl :
> Benjamin Peterson schrieb:
>> On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni wrote:
>>> Didn't a test fail because of this? seems the underlying issue is that this
>>> part of the stdlib didn't have enough test coverage. It seems that having
>>> very good/improving tes
On Wed, Feb 18, 2009 at 3:06 AM, Nick Coghlan wrote:
> Georg Brandl wrote:
>> Benjamin Peterson schrieb:
>>> Oh, does pylint support py3k now?
>>
>> I think you may have a point there, though I honestly don't know.
>
> I think it's a useful point in general - keeping something like pylint
> or pyc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 18, 2009, at 1:49 AM, Brett Cannon wrote:
If there are really enough fixes to warrant it, sure. Otherwise
would it be
worth more to just wait until after PyCon where there is a bigger
chance of
fixed issues?
Good point.
Barry
-BEGI
Georg Brandl wrote:
> Benjamin Peterson schrieb:
>> Oh, does pylint support py3k now?
>
> I think you may have a point there, though I honestly don't know.
I think it's a useful point in general - keeping something like pylint
or pychecker running correctly against the CPython trunk could be a
fr
Benjamin Peterson schrieb:
> On Tue, Feb 17, 2009 at 3:02 PM, Georg Brandl wrote:
>> Benjamin Peterson schrieb:
>>> On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni
>>> wrote:
Didn't a test fail because of this? seems the underlying issue is that this
part of the stdlib didn't have eno
On Tue, Feb 17, 2009 at 1:45 PM, "Martin v. Löwis" wrote:
> Don't expect too much
> help from other people - I have been waiting for volunteers to show up
> helping with the tracker for more than a year now.
>
I have been mostly a silent spectator around and would like to chip in.
Need some initi
27 matches
Mail list logo
