[Python-Dev] VS 2012 Express will support desktop apps

2012-06-09 Thread Christian Heimes 
Good news everybody!

Microsoft has announced that the free VS 2012 Express Edition (aka VS11)
will support desktop and console apps, too. Formerly only Metro apps
were supported by the free edition.

http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx

Christian
___
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] PEP 362 Second Revision

2012-06-09 Thread Calvin Spealman 
On Thu, Jun 7, 2012 at 10:41 AM, Yury Selivanov  wrote:
> Hello,
>
> The new revision of PEP 362 has been posted:
> http://www.python.org/dev/peps/pep-0362/

While the actual implementation is more complex, the PEP is a lot more
clear and direct than it first was. Great job!

I'm really looking forward to this, after working through essentially
the same problems as part of tracerlib. So this has a huge thumbs up
from me, fwiw.

> Thanks to Brett, Larry, Nick, and everybody else on python-dev
> for your corrections/suggestions.
>
> Summary of changes:
>
> 1. We don't cache signatures in __signature__ attribute implicitly
>
> 2. signature() function is now more complex, but supports methods,
> partial objects, classes, callables, and decorated functions
>
> 3. Signatures are always constructed on demand
>
> 4. Dropped the deprecation section
>
> The implementation is not aligned with the latest PEP yet,
> I'll try to update it tonight.
>
> Thanks,
> -
> Yury
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
___
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] backporting stdlib 2.7.x from pypy to cpython

2012-06-09 Thread Matti Picus 

  
  
On 8/06/2012 9:29 PM, Brett Cannon wrote:

  
  On Fri, Jun 8, 2012 at 2:21 PM, [email protected]

wrote:

  On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon

wrote:
> R. David already replied to this, but just to
reiterate: tests can always
> get updated, and code that fixes a bug (and leaving a
file open can be
> considered a bug) can also go in. It's just stuff like
code refactoring,
> speed improvements, etc. that can't go into Python 2.7
at this point.
  
  Thanks for the clarification!
  
> If/until the stdlib is made into its own repo, should
the various VMs
> consider keeping a common Python 2.7 repo that contains
nothing but the
> stdlib (or at least just modifications to those) so
they can modify in ways
> that CPython can't accept because of compatibility
policy? You could keep it
> on hg.python.org
(or wherever) and then all push to it. This might also be a
> good way to share Python implementations of extension
modules for Python 2.7
> instead of everyone maintaining there own for the next
few years (although I
> think those modules should go into the stdlib directly
for Python 3 as
> well). Basically this could be a test to see if
communication and
> collaboration will be high enough among the other VMs
to bother with
> breaking out the actual stdlib into its own repo or if
it would just be a
> big waste of time.
  
  I'd be up for trying this. I don't think it's easy to fork a
  subdirectory of CPython though - right now I just keep an
  unchanged
  copy of the 2.7 LIb in our repo (PyPy does the same, at least
  the last
  time I checked).



Looks like hg doesn't have support yet: http://stackoverflow.com/questions/920355/how-do-i-clone-a-sub-folder-of-a-repository-in-mercurial .
 
The only sane option I can see then is to keep doing what
  you and PyPy are doing and keep a copy of the stdlib, but now
  you all simply share the repo instead of keeping your own
  copies and possibly use subrepos to pull it into your own hg
  repos.



  
> P.S. Do we need a python-implementations mailing list
or something for
> discussing overall VM-related stuff among all VMs
instead of always bringing
> this up on python-dev? E.g. I wish I had a place where
I could get all the
> VM stakeholders' attention to make sure that importlib
as it stands in
> Python 3.3 will skip trying to import Python bytecode
properly (or if the
> VMs will simply provide their own setup function and
that won't be a worry).
> And I would have no problem with keeping it like
python-committers in terms
> of closed subscriptions, open archive in order to keep
the noise low.
  
  I think a python-implementations list would be a fantastic
  idea - I
  sometimes miss multi-implementation discussions in python-dev,
  or at
  least come in very late.



If other people agree then I will get Barry to create it. 
  

I will follow a path of contributing the changes using
  bugs.python.org. Suggested changes will be the minumum needed to
  make the stdlib modules functional on pypy

Thanks,

Matti

  

___
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] backporting stdlib 2.7.x from pypy to cpython

2012-06-09 Thread Brett Cannon 
On Friday, June 8, 2012, Antoine Pitrou wrote:

> Le 08/06/2012 20:29, Brett Cannon a écrit :
>
>>
>> > P.S. Do we need a python-implementations mailing list or
>>something for
>> > discussing overall VM-related stuff among all VMs instead of
>>always bringing
>> > this up on python-dev? E.g. I wish I had a place where I could
>>get all the
>> > VM stakeholders' attention to make sure that importlib as it
>>stands in
>> > Python 3.3 will skip trying to import Python bytecode properly
>>(or if the
>> > VMs will simply provide their own setup function and that won't
>>be a worry).
>> > And I would have no problem with keeping it like
>>python-committers in terms
>> > of closed subscriptions, open archive in order to keep the noise
>> low.
>>I think a python-implementations list would be a fantastic idea - I
>>sometimes miss multi-implementation discussions in python-dev, or at
>>least come in very late.
>>
>>
>> If other people agree then I will get Barry to create it.
>>
>
> Well, the question is, are many python-dev discussions CPython(specific?
> If not, then it doesn't make a lot of sense to create
> python-implementations (and it's one more subscription to manage for those
> of us who want to keep an eye on all core development-related discussions).
>
>
But the other VMs don't necessarily care about the development of the
language, so when the occasional thing comes up regarding all the VMs,
should that require they follow python-dev in its entirety? And I don't see
the list making sweeping decisions that would affect CPython and python-dev
without bringing it up there later. Think of the proposed list more like a
SIG than anything else.

-Brett


> Regards
>
> Antoine.
>
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> brett%40python.org
>


-- 
[sent from my iPad]
___
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