Re: [Python-Dev] Windows Toolchain

[Eric Pruitt]

I will keep a grace period in mind when I am posting. In my defense,
however, I had been working on the problem for some time before posting this
and my messages in quick succession were in response to the suggestions
people offered. The problem has arisen again but I will work on it some more
and will also post a detailed post on my GSoC blog of the process I went
through when I encountered the issue.

On Mon, Jul 13, 2009 at 16:24, "Martin v. Löwis"  wrote:

> > I am trying to build Python 3.1 on Windows XP Pro (32 bit) using
> > Microsoft Visual C++ Express Edition in order to test some modifications
> > I made to the _subprocess.c file as part of my Google Summer of Code
> > proposal.
>
> As a posting guideline, please be careful to not post too many messages
> in quick succession. If you run into a problem, try to solve it for
> yourself. If you fail, consult your mentor and/or wait a couple of
> hours. Then, when posting, summarize your findings and the alternatives
> that you tried unsuccessfully.
>
> If people learn that you post while being in the process of working
> on a problem, they will learn that it is better to wait a day or two
> before responding, in case you figure it out on your own.
>
> Regards,
> Martin
>
___
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] 2.6 object.__init__ & deling __new__

[Dino Viehland]

I'm updating IronPython to match CPython's behavior w/ for this issue:

http://bugs.python.org/issue1683368

One thing that I've noticed is that this doesn't seem to be respecting the 
deletion of attributes (on 2.6.2):

class x(object): pass

x().__init__(2,3,4) # throws - seems right

class x(object):
def __new__(cls, *args):
return object.__new__(cls)

x().__init__(2,3,4)  # doesn't throw - seems right

del x.__new__
x().__init__(2,3,4) # doesn't throw - I would expect this to throw.

Is this just a bug in CPython not updating whether __new__ has been defined?  
Or is there something that makes this behavior expected which I'm just missing?



___
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] 2.6 object.__init__ & deling __new__

[Benjamin Peterson]

2009/7/14 Dino Viehland :
> Is this just a bug in CPython not updating whether __new__ has been
> defined?  Or is there something that makes this behavior expected which I’m
> just missing?

There's a wonderful comment about this in typeobject.c:

/* You may wonder why object.__new__() only complains about arguments
   when object.__init__() is not overridden, and vice versa.

   Consider the use cases:

   1. When neither is overridden, we want to hear complaints about
  excess (i.e., any) arguments, since their presence could
  indicate there's a bug.

   2. When defining an Immutable type, we are likely to override only
  __new__(), since __init__() is called too late to initialize an
  Immutable object.  Since __new__() defines the signature for the
  type, it would be a pain to have to override __init__() just to
  stop it from complaining about excess arguments.

   3. When defining a Mutable type, we are likely to override only
  __init__().  So here the converse reasoning applies: we don't
  want to have to override __new__() just to stop it from
  complaining.

   4. When __init__() is overridden, and the subclass __init__() calls
  object.__init__(), the latter should complain about excess
  arguments; ditto for __new__().

   Use cases 2 and 3 make it unattractive to unconditionally check for
   excess arguments.  The best solution that addresses all four use
   cases is as follows: __init__() complains about excess arguments
   unless __new__() is overridden and __init__() is not overridden
   (IOW, if __init__() is overridden or __new__() is not overridden);
   symmetrically, __new__() complains about excess arguments unless
   __init__() is overridden and __new__() is not overridden
   (IOW, if __new__() is overridden or __init__() is not overridden).

   However, for backwards compatibility, this breaks too much code.
   Therefore, in 2.6, we'll *warn* about excess arguments when both
   methods are overridden; for all other cases we'll use the above
   rules.

*/



-- 
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] Windows Toolchain

[Eric Pruitt]

The problem appears resolved again and I have two posts on the issue on my
blog located at http://subdev.blogspot.com/. I was missing an MSVC++
run-time DLL and re-installing Visual C++ Express fixed the problem. A bit
of a somewhat random note -- looking through some of the buildbot output for
Python 3.1, I noticed that at one point, the bot compilations had the same
issue; Google 
Cache
.

On Mon, Jul 13, 2009 at 16:24, "Martin v. Löwis"  wrote:

> > I am trying to build Python 3.1 on Windows XP Pro (32 bit) using
> > Microsoft Visual C++ Express Edition in order to test some modifications
> > I made to the _subprocess.c file as part of my Google Summer of Code
> > proposal.
>
> As a posting guideline, please be careful to not post too many messages
> in quick succession. If you run into a problem, try to solve it for
> yourself. If you fail, consult your mentor and/or wait a couple of
> hours. Then, when posting, summarize your findings and the alternatives
> that you tried unsuccessfully.
>
> If people learn that you post while being in the process of working
> on a problem, they will learn that it is better to wait a day or two
> before responding, in case you figure it out on your own.
>
> Regards,
> Martin
>
___
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] 2.6 object.__init__ & deling __new__

[Dino Viehland]

Benjamin wrote:

> There's a wonderful comment about this in typeobject.c:
>

This is basically the same what I've gathered from the issue
description which was quite helpful.  But in this case we're
dealing with mutating the type object and changing whether
__new__ or __init__ exist at all at runtime - and
object.__new__/__init__ don't seem to be picking up on the
change.

I believe that the comments here w.r.t. mutability/immutability
are more about whether the instances are immutable and not
the type objects themselves - for example list vs tuple where
tuple has __new__ but no __init__.

Based upon the behavior I'm seeing it seems to me that the
presence of __new__ / __init__ must be getting cached somewhere
and the deletion isn't updating the cache and that's specifically
what struck me as odd here.



___
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] 2.6 object.__init__ & deling __new__

[P.J. Eby]

At 04:11 PM 7/14/2009 -0500, Benjamin Peterson wrote:
4. When __init__() is overridden, and the subclass __init__() 
calls   object.__init__(), the latter should complain about 
excess   arguments; ditto for __new__().


Actually, this rule is a PITA, because there's no good way to get rid 
of the warnings when you're trying to write MRO-agnostic mixins.


In other words, it negates many of the gains that were obtained by 
having new-style MROs, since you can no-longer write pass-through 
constructors that leave their arguments untouched.  Instead, every 
class must know ahead of time whether it will be the "last" class 
before 'object' -- thereby making it impossible to slip other mixins 
into the chain below them.


In effect, 2.6 forces you to have a common known base class *other* 
than 'object' in order to write co-operative classes.  :-(



___
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] Add an ExecutionLoader abc to importlib or to runpy?

[Brett Cannon]

I implemented get_filename() as specified in PEP 302 for importlib's source
and bytecode loaders and I was starting to create the ABC for importlib.abc,
but then I realized that perhaps the loader should live in runpy instead of
importlib.
Putting the new ABC in importlib keeps all PEP 302 ABCs in a single spot.
But this addition to the PEP 302 protocols is very specific to runpy and is
not directly required to make imports work (the implementation was just a
reshuffling of pre-existing code from one method to another). I am tempted
to leave the ABC out of importlib and stop at implementing get_filename()
for importlib.abc.PyLoader and PyPycLoader.

Any opinions?

-Brett
___
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