I'd appreciate if if you would go to
http://holdenweb.blogspot.com/
and register your vote on your intended migration timescale.
Thanks!
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Sorry, the dog ate my .sigline
I'll use the "no plans" response for my actual "no simple answer" real
response.
Richard
I'm going to abstain voting until 'public beta + about 1 year' is a choice.
James
regards
Steve
What are the additions that people find the most compelling?
One of the offered answers to the current question should be "never".
That is, I'm hoping to skip 3.0 and switch directly to PyPy.
Does this require JavaScript? If yes, count me as another "no" vote on
your survey. ;-)
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
The best way to get information on Usenet is not to ask a question, but
to post the wrong information.
> It seems that Python 3 is more significant for what it removes than
> what it adds.
That's certainly the focus of an explicitly backward-incompatible
upgrade, yes.
> What are the additions that people find the most compelling?
Most of the additions that will go into 2.6 are doing so because
they'll appear in 3.0. That's a benefit: anything from 3.0 that makes
sense to add to 2.6 will go in; the rest of 3.0's changes are mostly
backwards-incompatible (i.e. removals and conflicting changes).
I find the following compelling:
- 'str' becomes Unicode type, 'int' becomes unified-int-and-long
type <URL:http://www.python.org/dev/peps/pep-3100/>
- Consistent, unambiguous integer literal syntax
<URL:http://www.python.org/dev/peps/pep-3127/> and the 'bytes'
type for non-text strings
<URL:http://www.python.org/dev/peps/pep-3112/>
- Default source encoding is UTF-8
<URL:http://www.python.org/dev/peps/pep-3120/> and support for
non-ASCII identifiers
<URL:http://www.python.org/dev/peps/pep-3131/>
- Reorganisation of the standard library for consistency
<URL:http://www.python.org/dev/peps/pep-3108/>
- Renaming raw_input to input, so 'input()' does the obvious thing
<URL:http://www.python.org/dev/peps/pep-3111/>
- Clarification of 'raise' and 'except' semantics
<URL:http://www.python.org/dev/peps/pep-3109/>,
<URL:http://www.python.org/dev/peps/pep-3110/>
- Abstract Base Classes
<URL:http://www.python.org/dev/peps/pep-3119/>
- everything that's being added to 2.6 :-)
--
\ "I bought a self learning record to learn Spanish. I turned it |
`\ on and went to sleep; the record got stuck. The next day I |
_o__) could only stutter in Spanish." -- Steven Wright |
Ben Finney
Well, "No current plans" certainly includes "never", even though it
might not be quite assertive enough for your tastes.
I hope that PyPy will eventually become good enough to overtake CPython
as the preferred implementation - it certainly seems to have much
greater optimization possibilities than CPython.
I like how someone here characterized decorators - those silly @
things. They remind me of Perl. Not adding keywords for abstract and
static is like Perl not adding a keyword for class. But I know all
such additions are vigorously defended by the most ardent users of
each language.
- dict.items(), .values() and .keys() returns "dict views", and the
.iter*() removal
http://www.python.org/dev/peps/pep-3106/
- the new super()
http://www.python.org/dev/peps/pep-3135/
etc...
--
http://www.advogato.org/person/eopadoan/
Bookmarks: http://del.icio.us/edcrypt
I'd rather see Python 2.5 finished, so it just works.
All the major third-party libraries working and available with
working builds for all major platforms. That working set
of components in all the major distros used on servers.
The major hosting companies having that up and running on
their servers. Windows installers that install a collection
of components that all play well together.
That's what I mean by "working".
John Nagle
The fact that you compare and criticise the simple annotations like
static or abstract with the much more powerful decorator concept shows
that, despite being the maintainer of a
soon-to-be-ruling-the-python-world Python 3 fork, lack understanding of
even the most basic language features. Which isn't exactly news.[1]
The decorator syntax was vigorously discussed. I personally don't mind
the @-based syntax, but could live with anything else - because I like
and often need the feature for it's capabilities.
Maybe you should start using python more and _then_ start discussions
about it's features, when you have good grounds and can provide viable
alternatives? But I guess that's a wish that won't be granted....
Diez
>
>>
>> The fact that you compare and criticise the simple annotations like
>> static or abstract with the much more powerful decorator concept shows
>> that, despite being the maintainer of a
>> soon-to-be-ruling-the-python-world Python 3 fork, lack understanding of
>> even the most basic language features. Which isn't exactly news.[1]
>
> Don't you mean "lack appreciation for the non-basic language
> features"? static, class and abstract
> are basic language features that I appreciate. "decorators" have been
> in Python for only a small part of its existence, they aren't in the
> vast majority of languages (if any other language even has them) which
> means people write all kinds of software without them. Or rather, most
> of the software ever written didn't use decorators. Doesn't sound
> basic at all.
People did write all kinds of software in Assembler. And large portions of
these people complained about every feature that some new language
introduced.
All serious languages are turing-complete. So can we put away with this
non-sense argument right away, please?
>>
>> Maybe you should start using python more and _then_ start discussions
>> about it's features, when you have good grounds and can provide viable
>> alternatives? But I guess that's a wish that won't be granted....
>
> static and abstract keywords would seem to be very viable
> alternatives. Viable enough that several language designers used them.
As I said - you don't get it. The decorators (in conjunction with the
descriptor protocol - ever heard of that?) are very powerful yet lead as an
artifact to simple, declarative implementations of features you like,
namely static and abstract methods.
And as you seem being so reluctant to let new features creep into the
language, the introduction of new keywords you like?
Besides, those 'several language designers' seem to think that the
introduction of keywords isn't enough, but a general purpose annotation
scheme seems to be viable - or how do you explain e.g. JDK 1.5 Annotations?
Diez
Has any one actually converted any real code or significant bits of code
using the 3.0 converter (in the sandbox somewhere), and if so what kinds
of things actually failed?
Nothing I've read about 3.0 has alarmed me that much yet, but I've not
yet actually tried converting code for it (except a few extension modules,
which at least _compiled_ just fine against 3.0).
- Stephan
> Richard Jones wrote:
>> I'll use the "no plans" response for my actual "no simple answer"
>> real
>> response.
>>
>>
> So what we need is a poll on what the questions should be. I *love*
> c.l.py.
Does professional vs. personal use matter here? What if I plan to
switch in the morning or at midnight on the first solstice after the
second alpha release? Is Mercury or Venus in retrograde? These
things matter... :)
Erik Jones
Software Developer | Emma®
er...@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
> TheFlyingDutchman wrote:
> > It seems that Python 3 is more significant for what it removes than
> > what it adds.
> >
> > What are the additions that people find the most compelling?
>
> I'd rather see Python 2.5 finished, so it just works.
And I'd rather see peace on Earth and goodwill among men than _either_
Python 3 or your cherished "finished" 2.5 -- the comparison and implied
tradeoff make about as much sense as yours.
> All the major third-party libraries working and available with
> working builds for all major platforms. That working set
> of components in all the major distros used on servers.
> The major hosting companies having that up and running on
> their servers. Windows installers that install a collection
> of components that all play well together.
>
> That's what I mean by "working".
I.e., you mean tasks appropriate for maintainers of all the major
third-party libraries, distros, and hosting companies -- great, go
convince them, or go convince all warmongers on Earth to make peace if
you want an even harder tasks with even better potential impact on the
state of the world, then.
Alex
You said it was a most basic language feature. I still haven't heard
anything that leads me to believe that statement is correct. What
languages implemented decorators as a most basic language feature?
Python didn't have them for over a decade so it doesn't qualify.
>
> >> Maybe you should start using python more and _then_ start discussions
> >> about it's features, when you have good grounds and can provide viable
> >> alternatives? But I guess that's a wish that won't be granted....
>
> > static and abstract keywords would seem to be very viable
> > alternatives. Viable enough that several language designers used them.
>
> As I said - you don't get it. The decorators (in conjunction with the
> descriptor protocol - ever heard of that?) are very powerful yet lead as an
> artifact to simple, declarative implementations of features you like,
> namely static and abstract methods.
You said I had to provide a viable alternative. I did that. I haven't
heard of the descriptor protocol.
One of the problems with "getting" decorators is that they are not in
older books at all and newer books like Beginning Python from Novice
to Professional (c) 2005 Magnus Lie Hetland, that I own, devote almost
nothing to them. Out of 640 pages they are only mentioned
in one paragraph that is in a section titled "Static Methods and Class
Methods",(and followed by a class example with @staticmethod and
@classmethod).
So it seems like Magnus Lie Hetland didn't think they were very
important and he had Professional in his book title.
>
> And as you seem being so reluctant to let new features creep into the
> language, the introduction of new keywords you like?
I'm not against additions on principle.
>
> Besides, those 'several language designers' seem to think that the
> introduction of keywords isn't enough, but a general purpose annotation
> scheme seems to be viable - or how do you explain e.g. JDK 1.5 Annotations?
I certainly wouldn't call them a basic language feature. Java 1.0 came
out in January 1996, Java 1.5 in September 2004. It doesn't appear
that the language designer of Java, James Gosling, is still at the
wheel or BDFL. But yes, Java is showing signs of "complexity creep".
You'll be happy to know that I really dislike the C++ template syntax
and Java has decided to add something similar.
Actually the so called "total" languages aren't Turing-complete. I
think Coq is an example: every Coq function must return a value. So
Coq doesn't have any way to write an infinite loop, because that would
allow writing functions that fail to return. So there is no halting
program in Coq (every Coq program halts), which means Coq is not
Turing-complete. That allows Coq to generate code about which it can
make all kinds of guarantees that most languages can't (not simply
that the programs halt but that they actually fulfill their
computational specifications), so it's being used in various
high-assurance applications, though usually to write just the most
critical parts of a program, not the entire program. Of course it's a
matter of semantics but in some meaningful ways, I'd say Coq is a more
serious language than Python.
Here is a famous early paper explaining why Turing-completeness isn't
all it's cracked up to be:
http://sblp2004.ic.uff.br/papers/turner.pdf
This paper shows some of the advantages of the total approach.
Insofar as Python has an organization, it's not adequately managing
extension modules. Each extension module has its own infrastructure,
with its own build procedures, its own bug list, and its own maintainers.
There's not even an archive. Unlike CPAN, Cheese Shop is just a directory of
URLs.
Take a look at how Perl does it. Here are the instructions on
how to contribute to CPAN:
http://www.cpan.org/modules/04pause.html
There's a way to get your module into the system, a standardized format,
build, and installation procedure, and an archive which is mirrored.
There's a common bug reporting system. Modules abandoned by their
original developers are not lost, and can be "adopted" by someone else.
Python doesn't have any of this. And that's far more of a problem
than Python 3.x.
John Nagle
> > All serious languages are turing-complete. So can we put away with this
> > non-sense argument right away, please?
>
> You said it was a most basic language feature. I still haven't heard
> anything that leads me to believe that statement is correct. What
> languages implemented decorators as a most basic language feature?
> Python didn't have them for over a decade so it doesn't qualify.
>
Decorators are syntax sugar for higher order functions. Higher order
functions are a both a basic and a fundamental language feature, and
exist in many languages. The fact that you don't know this just
proves, once again, that you like to talk more than you like to learn.
I was talking about Python, the programming language that is discussed in
this NG.
> Python didn't have them for over a decade so it doesn't qualify.
Says who? For further comments, see below.
>>
>> >> Maybe you should start using python more and _then_ start discussions
>> >> about it's features, when you have good grounds and can provide viable
>> >> alternatives? But I guess that's a wish that won't be granted....
>>
>> > static and abstract keywords would seem to be very viable
>> > alternatives. Viable enough that several language designers used them.
>>
>> As I said - you don't get it. The decorators (in conjunction with the
>> descriptor protocol - ever heard of that?) are very powerful yet lead as
>> an artifact to simple, declarative implementations of features you like,
>> namely static and abstract methods.
>
> You said I had to provide a viable alternative. I did that. I haven't
> heard of the descriptor protocol.
Where did you do provide that alternative?
> One of the problems with "getting" decorators is that they are not in
> older books at all and newer books like Beginning Python from Novice
> to Professional (c) 2005 Magnus Lie Hetland, that I own, devote almost
> nothing to them. Out of 640 pages they are only mentioned
> in one paragraph that is in a section titled "Static Methods and Class
> Methods",(and followed by a class example with @staticmethod and
> @classmethod).
>
> So it seems like Magnus Lie Hetland didn't think they were very
> important and he had Professional in his book title.
I consider "core features of a language" the features that are part of the
specification and implementation. Neither do I care if there is anecdotal
evidence of prior usage in other languages, nor who or who not thinks they
are important enough to be dealt with in a book.
And above all, I don't consider the time things have been around _without_
any feature as proof of their irrelevance - or do you consider cars being
not core to western culture because they only have been around about 100
years, whereas horses have been there for thousands of years? Happy riding,
cowboy!
Python 2.4 has been released in 2003, btw - so decorators are around for 4
years now.
So unless you come up with a definition of "core feature of a language" that
someone respectable in the CS-community wrote that features "time being
around" or "random book authors consider worthy" or "persons lacking the
motivation to really dig into do finally get it", I consider your
definition worthless. Agreed?
>>
>> And as you seem being so reluctant to let new features creep into the
>> language, the introduction of new keywords you like?
>
> I'm not against additions on principle.
>
>>
>> Besides, those 'several language designers' seem to think that the
>> introduction of keywords isn't enough, but a general purpose annotation
>> scheme seems to be viable - or how do you explain e.g. JDK 1.5
>> Annotations?
>
> I certainly wouldn't call them a basic language feature. Java 1.0 came
> out in January 1996, Java 1.5 in September 2004. It doesn't appear
> that the language designer of Java, James Gosling, is still at the
> wheel or BDFL. But yes, Java is showing signs of "complexity creep".
> You'll be happy to know that I really dislike the C++ template syntax
> and Java has decided to add something similar.
Again, your anecdotal language feature definition is nonsense.
By the way, considering generics and C++-templates as "something similar"
shows the inclined beholder that there are other languages out there you
don't really understand.
Diez
Which of the common languages have higher order functions and what is
the syntax?
> "Diez B. Roggisch" <de...@nospam.web.de> writes:
>> All serious languages are turing-complete. So can we put away with this
>> non-sense argument right away, please?
>
> Actually the so called "total" languages aren't Turing-complete. I
> think Coq is an example: every Coq function must return a value. So
<snip/>
Please, Paul. There is no need to hijack every thread to show off your mad
functional and wicked staticly typed programming language skillz. We had
that discussion at a different time, and you very well know that with
serious I didn't mean "can be used to program rockets that don't fall of
the earth", but that aren't toy-languages used to solve real-world
problems.
Diez
> Which of the common languages have higher order functions and what is
> the syntax?
C, C++, Pascal, Perl, PHP, Ruby have them. And of course the functional
languages, most notably Lisp and Scheme as you asked for common languages.
Don't know if C#'s delegates qualify.
Ciao,
Marc 'BlackJack' Rintsch
I had the impression you were saying it was a basic language feature
of most languages. In any event Guido Van Rossum didn't include them
for over a decade. If he felt they were a basic language feature it
seems that he would have included them in 1991.
>
>
>
> >> >> Maybe you should start using python more and _then_ start discussions
> >> >> about it's features, when you have good grounds and can provide viable
> >> >> alternatives? But I guess that's a wish that won't be granted....
>
> >> > static and abstract keywords would seem to be very viable
> >> > alternatives. Viable enough that several language designers used them.
>
> >> As I said - you don't get it. The decorators (in conjunction with the
> >> descriptor protocol - ever heard of that?) are very powerful yet lead as
> >> an artifact to simple, declarative implementations of features you like,
> >> namely static and abstract methods.
>
> > You said I had to provide a viable alternative. I did that. I haven't
> > heard of the descriptor protocol.
>
> Where did you do provide that alternative?
def static
def abstract
I was not providing an alternative for decorators.
>
> > One of the problems with "getting" decorators is that they are not in
> > older books at all and newer books like Beginning Python from Novice
> > to Professional (c) 2005 Magnus Lie Hetland, that I own, devote almost
> > nothing to them. Out of 640 pages they are only mentioned
> > in one paragraph that is in a section titled "Static Methods and Class
> > Methods",(and followed by a class example with @staticmethod and
> > @classmethod).
>
> > So it seems like Magnus Lie Hetland didn't think they were very
> > important and he had Professional in his book title.
>
> I consider "core features of a language" the features that are part of the
> specification and implementation. Neither do I care if there is anecdotal
> evidence of prior usage in other languages, nor who or who not thinks they
> are important enough to be dealt with in a book.
By that definition isn't anything that is part of a language a core
feature? Weren't we talking about basic features?
>
> And above all, I don't consider the time things have been around _without_
> any feature as proof of their irrelevance - or do you consider cars being
> not core to western culture because they only have been around about 100
> years, whereas horses have been there for thousands of years? Happy riding,
> cowboy!
A relevant analogy would talk about a feature of cars that was not on
them in the beginning but has been added later and whether it was a
basic (or now, core) feature. Your definition of core feature given
above means that anything on a car when it comes out of the factory is
a core feature.
>
> Python 2.4 has been released in 2003, btw - so decorators are around for 4
> years now.
>
> So unless you come up with a definition of "core feature of a language" that
> someone respectable in the CS-community wrote that features "time being
> around" or "random book authors consider worthy" or "persons lacking the
> motivation to really dig into do finally get it", I consider your
> definition worthless. Agreed?
>
Since you defined a core feature (haven't seen your definition of a
basic feature) as anything in the specification or implementation, I
agree that it makes sense for you to disregard anything that limits
core features to something less than everything.
> >> Besides, those 'several language designers' seem to think that the
> >> introduction of keywords isn't enough, but a general purpose annotation
> >> scheme seems to be viable - or how do you explain e.g. JDK 1.5
> >> Annotations?
>
> > I certainly wouldn't call them a basic language feature. Java 1.0 came
> > out in January 1996, Java 1.5 in September 2004. It doesn't appear
> > that the language designer of Java, James Gosling, is still at the
> > wheel or BDFL. But yes, Java is showing signs of "complexity creep".
> > You'll be happy to know that I really dislike the C++ template syntax
> > and Java has decided to add something similar.
>
> Again, your anecdotal language feature definition is nonsense.
>
> By the way, considering generics and C++-templates as "something similar"
> shows the inclined beholder that there are other languages out there you
> don't really understand.
For me understanding is all I can hope to attain. Really understanding
is something I must yield to the corps d'elite.
What is the syntax of a higher order function in C, C++ and Pascal?
In this case I asked it as part of the original question and it was
ignored. I have programmed in C and C++ and a little Pascal many years
ago. I don't remember anything about Higher Order Functions and would
like to see exactly how you do it and to verify the contention.
void qsort(int *array, int length, int width, int (*compare)());
is a C library example. I think we'd describe qsort as a HOF since
one of its arguments (the comparison routine) is a function. We
wouldn't say that C has first class functions like Python or Scheme
does, since you can't create new functions at runtime.
Perhaps you could do a bit of independent research. Then your messages
to the group could contain more thoughtful questions and responses.
Jean-Paul
You could just google for it. Just in case your connection to google
or other similar search engines has been disabled for some reason,
here are some links.
Try for instance
http://okmij.org/ftp/c++-digest/Lambda-CPP-more.html#Ex3
or
http://www.cc.gatech.edu/~yannis/fc++/
or
http://www.boost.org/libs/mpl/doc/tutorial/higher-order.html
francesco
Or bind resources of these pocket protectors that otherwise would lead to
answers for people that do seek enlightment...
Diez
I don't think it would be correct to characterize my posts as not
seeking enlightenment. I do also happen to voice my opinion which
seems appropriate since this can be characterized as a discussion
group. It theoretically is possible for a discussion group to tolerate
opinions that diverge from the majority.
One issue I have with this group and that I encountered many years ago
in the Perl group is that there is no separate group
comp.lang.python.beginner where you can ask questions without getting
hit with RTFM! and the like.
>
>>
>> Or bind resources of these pocket protectors that otherwise would lead to
>> answers for people that do seek enlightment...
>
> I don't think it would be correct to characterize my posts as not
> seeking enlightenment. I do also happen to voice my opinion which
> seems appropriate since this can be characterized as a discussion
> group. It theoretically is possible for a discussion group to tolerate
> opinions that diverge from the majority.
I would characterize
"""
I like how someone here characterized decorators - those silly @
things. They remind me of Perl. Not adding keywords for abstract and
static is like Perl not adding a keyword for class.
"""
not as seeking enlightenment, but as pure trolling. Disqualifying features
without actually understanding them as "silly" certainly doesn't lie on one
of the many path's to enlightenment known man - which to my knowledge
usually require more humble approaches....
> One issue I have with this group and that I encountered many years ago
> in the Perl group is that there is no separate group
> comp.lang.python.beginner where you can ask questions without getting
> hit with RTFM! and the like.
And I wish people that have no clue about the deeper workings of Python
wouldn't insist on commenting on these in inappropriate ways as above, but
instead try and _understand_ them before debuking them or suggesting
changes.
Diez
> One issue I have with this group and that I encountered many years ago
> in the Perl group is that there is no separate group
> comp.lang.python.beginner where you can ask questions without getting
> hit with RTFM! and the like.
Which shows once again that you're trying to break the world record of
being wrong in as many sentences as possible:
http://mail.python.org/mailman/listinfo/tutor
You would do yourself (and others) a favor by migrating there for a
few weeks or months.
George
It's not that we don't want you. it's just that you don't seem to
realize how annoying you can be.
n the other hand, if you *do* realize how annoying you can be then
please leave now and never come back ;-)
Being in a land where every nit can be picked, I am surprised that you
offered up a mailing list when I was asking for a newsgroup.
Does Perl support extension modules, and if so, are they so prevalent
as in Python ? Either case, bringing up CPAN is moot in this case;
nothing can force an external open source contributor to maintain or
provide binaries for his packages. How is this a problem of the
*language* ?
George
Now at 98.75% ...
nntp://news.gmane.org/gmane.comp.python.tutor
--
Carsten Haese
http://informixdb.sourceforge.net
Some posts seek enlightenment, some voice opinions. Opinions aren't
always voiced humbly. I don't think you will have to look far for
examples of people other than myself not expressing opinions humbly.
>
> > One issue I have with this group and that I encountered many years ago
> > in the Perl group is that there is no separate group
> > comp.lang.python.beginner where you can ask questions without getting
> > hit with RTFM! and the like.
>
> And I wish people that have no clue about the deeper workings of Python
> wouldn't insist on commenting on these in inappropriate ways as above, but
> instead try and _understand_ them before debunking them or suggesting
> changes.
>
I will grant you that "silly" is too strong a word to use in a group
of ardent users but I think it should be completely valid to gripe
about the syntax at least once.
A reasonable question is being asked.
Colin W.
John, can't you please piss off?
Thanks, Kay
> That's because the tutor list doesn't offer a newsgroup. He was probably
> just trying to get rid of you.
>
> Now at 98.75% ...
Not sure if that's the reading on your trollmeter or on the meter that
measures what percentage of your posts you get huffy.
I'm usually pretty quiet on this list. That's what I find is the
best way to participate. However, I'm going to have to speak up and
point out that that response is exactly the type of comment and/or
reasoning that everyone here is trying to explain to you. The
resources are available for you to educate yourself. Semantic
arguments such as this are, at best, at a junior high level. You are
completely free to ask any question (about Python) you want here --
just don't argue with the people giving you the answers. And, to
address the actual content of that response: nobody, online or off,
in newsgroups or on mailing lists, likes a nitpick. So, please,
quit. I'd prefer you didn't leave and, instead, decided to actually,
actively get along with the others here. I think some of the
question you've begun threads with have been both good and valid.
It's just that you need some work on your e-people skills, man.
Erik Jones
Software Developer | Emma®
er...@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
crabbi-ly y'rs - steve
Ah, it's not usenet without someone speaking from ignorance! :)
Richard
Yes, Perl supports non-Perl extension modules. But most of the
important ones are either maintained as part of the standard Perl distribution,
or supported by the organization that provides whatever they link to.
For example, MySQL AB supports a Perl binding to MySQL, but not a
Python binding.
John Nagle
Well, since the converter is designed to convert 2.6 and above, and since
there isn't much Python 2.6 code out there yet, I'd say nothing
significant. :)
Anyways, it is not designed to convert arbitrary code that's lying
around: it's designed to convert a supported subset of Python 2.6+ into
Python 3.0. You'd have to write "transitional Python" to use the tool.
Carl Banks
1) Migrate to 3000 fairly soon after release for scripts and new
projects for which required third party modules are available for 3k
2) Migrate existing projects to 3k a) when frameworks/modules that
they use are available and b) if and when doing so would be
advantageous.
I suspect that many of the projects I have that are solid and are in
no imminent need of development will remain <3k for several years.
Cheers,
--
Ant
And what's your point, other than that apparently MySQL AB doesn't care
about Python?
> Correct me if I am wrong, but none of those examples showed something
> in C++ similar to a decorator in Python - that is, unique syntax in
> the language for implementing a Higher Order Function. One thing I
> will say about those examples is that they make Python decorators look
> sweet!
That is exactly one of the points in having decorators, as far as I
can tell. Namely, that higher order functions are easily implemented,
if and when needed.
Francesco
I was thinking of starting work on converting Python FIT to 3.0, and
then they posted PEP 3137. I think it's a real good idea, but it shows
that 3.0a1 isn't ready for a conversion effort.
http://www.python.org/dev/peps/pep-3137/
I'll look at it again in a year or so.
John Roth
When 3.0b1 comes out is probably the time to start looking seriously
at conversion. Until then, major course corrections (like PEP 3137)
will still be a possibility. Before the first beta, the best idea is
probably just to keep a watchful eye on the development to see if you
spot any show-stopper problems that might lead to the need for such a
course correction :)
Regards,
Nick.
It was people who did that, partly by trying to convert or write small
snippets of code, who found problems and persuaded Guido that PEP 3137 was
needed.
I'm sure the community at large would be happy to chip in an annual
fee to help build/maintain this infrastructure: I know my firm would.
PS: IMHO The growth of Ruby is, to a large extent, due to easy
installation of modules via its gem system...
On Sep 28, 6:53 pm, John Nagle <na...@animats.com> wrote:
> Insofar as Python has an organization, it's not adequately managing
> extension modules. Each extension module has its own infrastructure,
> with its own build procedures, its own bug list, and its own maintainers.
> There's not even an archive. Unlike CPAN, Cheese Shop is just a directory of
> URLs.
>
> Take a look at how Perl does it. Here are the instructions on
> how to contribute to CPAN:
>
> http://www.cpan.org/modules/04pause.html
>
> There's a way to get your module into the system, a standardized format,
> build, and installation procedure, and an archive which is mirrored.
> There's a common bug reporting system. Modules abandoned by their
> original developers are not lost, and can be "adopted" by someone else.
>
> Python doesn't have any of this. And that's far more of a problem
> than Python 3.x.
>
> John Nagle
I would imagine it's the SpamBayes score your posts are currently
getting on Steve's machine.
Tim Delaney
The options should have all been relative to the release date.
Options one and two might very well be the same (yes, I know, but shit
happens). Also, you're relying on people knowing the current
timeframe for 3.0.
--
Nick