It's a nice beast but:
- it's not built in. Should it be? I think it should.
- about readme and manifest.in:
"You could add to your template a file called readme.rst . Inside of it you can add the following code that will generate this:"
i dont want to add, i want it already added :).. readme is something typical, it's not rare habit for some geeks how wants to customize it all!! the same with manifest.in..
what do you think? iteractive creation is big plus..
It's a nice beast but:
- it's not built in. Should it be? I think it should.
- about readme and manifest.in:
"You could add to your template a file called readme.rst . Inside of it you can add the following code that will generate this:"
i dont want to add, i want it already added :).. readme is something typical, it's not rare habit for some geeks how wants to customize it all!! the same with manifest.in..
what do you think? iteractive creation is big plus..
You can suggest this to python-ideas but I really doubt you will get any traction. The sdtlib don't get new features these days because it's a burden
to maintain high level tool on a 2 years release cycle
> - about readme and manifest.in:
> "You could add to your template a file called readme.rst . Inside of it you can add the following code that will generate this:"
> i dont want to add, i want it already added :).. readme is something typical, it's not rare habit for some geeks how wants to customize it all!! the same with manifest.in..
> what do you think? iteractive creation is big plus..
I am not sure I get your remark on this. I pointed to this page to show a typical use case of building Paster Templates, so you can bootstrap your projects boiler-plate code
So IOW everyone's free to create any kind of template :)
On Fri, 21 Sep 2012 14:50:36 +0100, Mark Lawrence wrote:
> On 21/09/2012 14:13, xliiv wrote:
>> Why is this '2 years release cycle'?
> Because there aren't enough volunteers to get it done any faster?
Because if it were any faster, it would piss off a lot of people.
Python's release cycle is actually closer to 18 months for minor releases
(3.2 -> 3.3, for example), and 10 years for major releases (2.x -> 3.x). But consider, C and C++ don't have minor releases *at all*. The last versions of those two languages are C99 and C+98 -- that's FOURTEEN YEARS since the last version of C++. And Java hasn't had a major feature update since 2006.
For a programming language with a lot of corporate use, Python already seems like it changes at the drop of a hat.
> On Fri, 21 Sep 2012 14:50:36 +0100, Mark Lawrence wrote:
>> On 21/09/2012 14:13, xliiv wrote:
>>> Why is this '2 years release cycle'?
>> Because there aren't enough volunteers to get it done any faster?
> Because if it were any faster, it would piss off a lot of people.
> Python's release cycle is actually closer to 18 months for minor releases
> (3.2 -> 3.3, for example), and 10 years for major releases (2.x -> 3.x). > But consider, C and C++ don't have minor releases *at all*. The last > versions of those two languages are C99 and C+98 -- that's FOURTEEN YEARS > since the last version of C++. And Java hasn't had a major feature update > since 2006.
"C++0x was the working name of a new ISO C++ standard, which was then
released in 2011 as C++11 ..."
according to http://gcc.gnu.org/projects/cxx0x.html
And it replaced C++03, released in 2003.
> For a programming language with a lot of corporate use, Python already > seems like it changes at the drop of a hat.
On Fri, 21 Sep 2012 13:26:32 -0400, Dave Angel wrote:
> On 09/21/2012 11:54 AM, Steven D'Aprano wrote:
>> Python's release cycle is actually closer to 18 months for minor
>> releases (3.2 -> 3.3, for example), and 10 years for major releases
>> (2.x -> 3.x). But consider, C and C++ don't have minor releases *at
>> all*. The last versions of those two languages are C99 and C+98 --
>> that's FOURTEEN YEARS since the last version of C++. And Java hasn't
>> had a major feature update since 2006.
> "C++0x was the working name of a new ISO C++ standard, which was then
> released in 2011 as C++11 ..."
> according to http://gcc.gnu.org/projects/cxx0x.html
<steve+comp.lang.pyt...@pearwood.info> wrote:
> But consider, C and C++ don't have minor releases *at all*. The last
> versions of those two languages are C99 and C+98 -- that's FOURTEEN YEARS
> since the last version of C++. And Java hasn't had a major feature update
> since 2006.
> For a programming language with a lot of corporate use, Python already
> seems like it changes at the drop of a hat.
Hang on, you're conflating the language and its implementation. C and
C++ don't have minor releases, because you're looking only at the
language. On the other hand, gcc has major.minor.revision releases,
because it's possible for the compiler to have trivial bugs that merit
a small bugfix, or minor changes that perhaps enhance the stdlib.
The way I see it, a Python minor release shouldn't normally be a
problem to an active developer, but is too big a change to push
quietly to active scripts. That's a lot smaller than a release of a
new C/C++ spec; more akin to the next version of Microsoft Visual C++,
which comes out every couple of years ish. And as DaveA (no relation
to me, but I love the coincidence of surname AND signature style)
pointed out, there have been C++ spec updates since 98.
Python's release schedule is plenty fast enough. It's already
outstripping the packagers in Debian and Red Hat. Fortunately it's
pretty easy to whip up your own Python straight from source and 'make
altinstall' to keep things happily parallel. You want faster releases?
You got 'em.
On Sat, 22 Sep 2012 03:44:55 +1000, Chris Angelico wrote:
> On Sat, Sep 22, 2012 at 1:54 AM, Steven D'Aprano
> <steve+comp.lang.pyt...@pearwood.info> wrote:
>> But consider, C and C++ don't have minor releases *at all*. The last
>> versions of those two languages are C99 and C+98 -- that's FOURTEEN
>> YEARS since the last version of C++. And Java hasn't had a major
>> feature update since 2006.
>> For a programming language with a lot of corporate use, Python already
>> seems like it changes at the drop of a hat.
> Hang on, you're conflating the language and its implementation.
No I'm not. CPython is the reference implementation of Python the language. There is no ISO standard for Python (nor is there likely to be any time soon) so Python the language is more-or-less what CPython the implementation does.
[...]
> Python's release schedule is plenty fast enough. It's already
> outstripping the packagers in Debian and Red Hat.
And has for a long time, well back to Python 1.5 days if I remember correctly.
> Fortunately it's
> pretty easy to whip up your own Python straight from source and 'make
> altinstall' to keep things happily parallel. You want faster releases?
> You got 'em.
But not faster than ≈18 months between minor releases. Not unless you fork and do it yourself.
<steve+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 22 Sep 2012 03:44:55 +1000, Chris Angelico wrote:
>> On Sat, Sep 22, 2012 at 1:54 AM, Steven D'Aprano
>> <steve+comp.lang.pyt...@pearwood.info> wrote:
>>> For a programming language with a lot of corporate use, Python already
>>> seems like it changes at the drop of a hat.
>> Hang on, you're conflating the language and its implementation.
> No I'm not. CPython is the reference implementation of Python the
> language. There is no ISO standard for Python (nor is there likely to be
> any time soon) so Python the language is more-or-less what CPython the
> implementation does.
True, though not entirely; there are plenty of CPython behaviours that
aren't strictly specified, and other Pythons don't have to comply.
>> Fortunately it's
>> pretty easy to whip up your own Python straight from source and 'make
>> altinstall' to keep things happily parallel. You want faster releases?
>> You got 'em.
> But not faster than ≈18 months between minor releases. Not unless you
> fork and do it yourself.
Why wait for a release? Just build with whatever patches you want to
build with. That's what I do with a lot of oddments of software. Well,
actually, what I tend to do is simply build HEAD (or whatever hg calls
it) as of when I want it, and update whenever I feel like it. :)
On Sep 21, 10:14 pm, xliiv <tymoteusz.jankow...@gmail.com> wrote:
> On Friday, September 21, 2012 1:08:23 PM UTC+2, Tarek Ziadé wrote:
> > Python Paste is probably what you are looking for - see
> It's a nice beast but:
> - it's not built in. Should it be? I think it should.
There needs to be a distinction at some point between Python as
runtime and development environments. If you assume that there are
more users of Python code than developers, then cluttering it with
more developer-only tools is a waste of resources for those end users.
Also: developers are fussy about their environments. One person's vi
is another person's emacs. We keep various package skeletons in our
git repository, and that works well for us, so adding Paste to Python
is just more useless kruft from our perspective.
And: easy_install/pip install paste isn't exactly crippling to type.
> - about readme and manifest.in:
> "You could add to your template a file called readme.rst"
> i dont want to add, i want it already added :)
If you'd just did as they asked, you'd already have this issue
resolved by now.
If you're waiting for the standard library to scratch your itch for
you, you're going to be waiting for a long, _long_ time.
> On Sep 21, 10:14 pm, xliiv <tymoteusz.jankow...@gmail.com> wrote:
>> On Friday, September 21, 2012 1:08:23 PM UTC+2, Tarek Ziadé wrote:
>>> Python Paste is probably what you are looking for - see
>> It's a nice beast but:
>> - it's not built in. Should it be? I think it should.
> There needs to be a distinction at some point between Python as
> runtime and development environments. If you assume that there are
> more users of Python code than developers, then cluttering it with
> more developer-only tools is a waste of resources for those end users.
> Also: developers are fussy about their environments. One person's vi
> is another person's emacs. We keep various package skeletons in our
> git repository, and that works well for us, so adding Paste to Python
> is just more useless kruft from our perspective.
> And: easy_install/pip install paste isn't exactly crippling to type.
>> - about readme and manifest.in:
>> "You could add to your template a file called readme.rst"
>> i dont want to add, i want it already added :)
> If you'd just did as they asked, you'd already have this issue
> resolved by now.
> If you're waiting for the standard library to scratch your itch for
> you, you're going to be waiting for a long, _long_ time.
Batteries are batteries, not flashlights, phone, radios, toys, clickers, etc.
> > > - it's not built in. Should it be? I think it should.
> > You can suggest this to python-ideas but I really doubt you will get any
> > traction. The sdtlib don't get new features these days because it's a burden
> > to maintain high level tool on a 2 years release cycle
> Why is this '2 years release cycle'?
This is good in python to focus on comming HW patforms with varied parameters as the industry is advacing toward all way to avoid a heavy landing of the IT and electronics industry.
> > > - it's not built in. Should it be? I think it should.
> > You can suggest this to python-ideas but I really doubt you will get any
> > traction. The sdtlib don't get new features these days because it's a burden
> > to maintain high level tool on a 2 years release cycle
> Why is this '2 years release cycle'?
This is good in python to focus on comming HW patforms with varied parameters as the industry is advacing toward all way to avoid a heavy landing of the IT and electronics industry.
