The Artima Developer Community
Sponsored Link

Weblogs Forum
More Questions About Python 3000 Answered

22 replies on 2 pages. Most recent reply: Jun 24, 2008 12:10 PM by sumanta mukherjee

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 22 replies on 2 pages [ « | 1 2 ]
Grzegorz Staniak

Posts: 1
Nickname: gstaniak
Registered: Aug, 2007

A general question about Py3k motivation Posted: Aug 8, 2007 5:12 AM
Reply to this message Reply
Advertisement
Hi,

Is Python 3000 actually worth the effort? I mean, voices from developers of high-profile projects (Zope, Twisted) can be heard saying they have no intention to port to py3k. This, together with the inconveniences of including two Pythons at the same time in a distribution, could mean a slow adoption rate and the status of, say, the Vista of Python releases. Was py3k necessary? I know, a stupid question to ask. But couldn't the goals of this release be achieved through the familiar cycle of "from __future__" imports, then going mainstream, then obsoleting old features? I suppose for syntax changes this could be tricky, if not impossible. But are the changes urgent enough to justify the risk taken?

Regards,
--
Grzegorz Staniak <gstaniak _at_ gmail *dot* com>

Larry Riedel

Posts: 2
Nickname: larryr
Registered: Jan, 2003

Re: A general question about Py3k motivation Posted: Aug 9, 2007 7:10 PM
Reply to this message Reply
Presuming the intra-process concurrency support in the most mainstream Python runtime(s) will be comparable to Java, and the use of function annotations will be ubiquitous, I think a /lot/ more Python code will be written in 3.x and beyond than was written before that, and any difficulty with the 2.x to 3.x transition will be little more than a historical footnote.


Larry

Petr Prikryl

Posts: 2
Nickname: pepr
Registered: Aug, 2007

Re: More Questions About Python 3000 Answered Posted: Aug 13, 2007 6:43 AM
Reply to this message Reply
> > I believe that list comprehensions will actually be
> > syntactic sugar for list(genexp) in Python 3000.
>
> Correct.
>
> Also note that you don't need to parenthesize a generator
> expression when it's the sole argument to a function, so
> Bjørn's example list([ e for e in l ]) can
> actually be written list(e for e in l)
> already.

I like to hear that. I would like also to see the alternative name for the list comprehension in Python 3000. It looks strange to beginners and it is probably difficult to translate the term into other human languages (at least into the Czech one). I understand that it may be the part of Python folklore. On the other hand...

If double (or single) quote char is considered a string constructor in many languages, then [...] in Python (with the things inside) is a list constructor. If I want to have some special name for generator expression, then probably the alternative name could be the list generator.

Petr Prikryl

Posts: 2
Nickname: pepr
Registered: Aug, 2007

Re: More Questions About Python 3000 Answered Posted: Aug 13, 2007 6:48 AM
Reply to this message Reply
Correction of myself:

> [...] If I want to have some special name for generator
> expression
, then probably the alternative name could
> be the list generator.

...should be...

If I want to have some special name for [ generator expression ], then probably the alternative name could be the list generator.

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: More Questions About Python 3000 Answered Posted: Aug 13, 2007 10:25 AM
Reply to this message Reply
> (proposal to rename list comprehensions and generator expressions)


Actually, list comprehension is known in other languages too (e.g. Haskell) and was taken from mathematics. So I'm sure there is a translation into Polish, unless there is no math literature translated into Polish. :-)

The name "generator expression" was discussed endlessly when it was first introduced; I doubt that we'll be able to come up with a better name.

amit upadhyay

Posts: 2
Nickname: n8d10021
Registered: Jul, 2007

Re: More Questions About Python 3000 Answered Posted: Aug 14, 2007 5:45 AM
Reply to this message Reply
> You can copy the annotations just like the docstring:
>
> _func.__annotations__ = f.__annotations__.copy()

This takes care of my doubts. Thankyou.

> No. In general the signature of a subclass __init__
> doesn't have to match the signature of the base class
> __init__ so it would be a mistake to do something like
> this automatically; and deducing that the signatures are
> actually the same would require way too much understanding
> in the compiler.

That may be so, but what if there was a decorator may be to say that the signatures are same. You may be aware that, esp in GUI class hierarchies, we have a lot of override chains that just calles the super(SomeClass, self).__current_method__(*args, **kw). Having them kill annotations will defeat the purpose of annotation.

I guess there can be a few annotation related decorators:

* @preserves_signature. This will follow the super logic, and find the nearest super, and .copy() its annotation.

This might take as keyword arguments the new arguments added that were not there in the base method.


class BaseClass:
...

class NewClass(BaseClass):
@preserves_signature(new_var="annotation of new vars")
def __init__(self, new_var, *args, **kw):
self.new_var = new_var
super(NewClass, self).__init__(*args, **kw)


This will effectively copy the annotations from BaseClass.__init__ and add annotation for new_var, and apply to new __init__.

This leave the matter of changing annotation for return type. That too can be handled by similar means.

Is this what you think things will go? or is there still some gap in my understanding?

ian o

Posts: 8
Nickname: iano
Registered: Aug, 2007

Re: A general question about Py3k motivation Posted: Aug 15, 2007 1:03 AM
Reply to this message Reply
As i understand it, there is no strong motivation to move to python 3.0, that is not the point!
Whilst most releases focus on what can ADD- having a release without guaranteeing backward compatibility puts the focus on what to REMOVE.
So 3.0 is all about what should be removed to provide a better base to move forward. Which means the incentive will come in future releases when the improved base is actually built on.
Don't worry if people don't rush to move to 3.0, by 3.1 or 3.2 the reasons for moving forward should be more apparent!

Why move to 3.0? Just to get the deleted features deleted?

As i said, the job of 3.0 being to remove the deadwood that block moving forward means it is all about REMOVING things and not about adding. Expect 3.1 to have backlog of additions, with the only additions on 3.0 being cases where a new substitute is immediately required for the old. At 3.0 the 'emergency' substitutes will be in their first iteration, and will not doubt evolve.

It will take a while for the full wisdom of 3.0 to emerge, but the logic is sound and the logic says that 3.0 will not itself be the compelling version- but it will build a better base for future versions.

(where hopefully one day a 'where' clause will become part of the language :) )

sumanta mukherjee

Posts: 1
Nickname: sumanta
Registered: Jun, 2008

Re: More Questions About Python 3000 Answered Posted: Jun 24, 2008 12:10 PM
Reply to this message Reply
There is one query which I have tried and have not got any answers from anywhere and so I thought of asking here. I am not sure if this is the right forum.

Anyway, this is regarding of embedding of Python code in C++.

Is it possible to embed Python GUI code inside C++.

I tried out the following
At Python prompt.
import Tkinter
Tkinter._test().

This works correctly.

When I try to import the same module Tkinter from C++ code and then try to call the test function it crashes. Not sure why this could be the case.

Regards
SM.

Flat View: This topic has 22 replies on 2 pages [ « | 1  2 ]
Topic: More Questions About Python 3000 Answered Previous Topic   Next Topic Topic: Open Standards vs Open Source?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us