Does python have built command for package skeleton creation?

[xliiv]

Like the topic.. . I found this:

http://learnpythonthehardway.org/book/ex46.html

it seems fine, but shouldn't be an interactive (with CLI API) script creating that? It's a lot of effort for common work.

I can contribute but i have to know that i'm not reinvent a wheel.

[Tarek Ziadé]

Python Paste is probably what you are looking for - see
http://lucasmanual.com/mywiki/PythonPaste for example

[xliiv]

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..

[xliiv]

On Friday, September 21, 2012 1:08:23 PM UTC+2, Tarek Ziadé wrote:

[Tarek Ziadé]

On 9/21/12 2:14 PM, xliiv wrote:
>
> Python Paste is probably what you are looking for - see
>
> http://lucasmanual.com/mywiki/PythonPaste for example
> It's a nice beast but:
> - 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

> - 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 :)

Cheers
Tarek

[xliiv]

On Friday, September 21, 2012 3:04:02 PM UTC+2, Tarek Ziadé wrote:
> On 9/21/12 2:14 PM, xliiv wrote:
>
> >
>
> > Python Paste is probably what you are looking for - see
>
> >
>
> > http://lucasmanual.com/mywiki/PythonPaste for example
>
> > It's a nice beast but:
>
> > - 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'?

[xliiv]

On Friday, September 21, 2012 3:04:02 PM UTC+2, Tarek Ziadé wrote:
> On 9/21/12 2:14 PM, xliiv wrote:
>
> >
>
> > Python Paste is probably what you are looking for - see
>
> >
>
> > http://lucasmanual.com/mywiki/PythonPaste for example
>
> > It's a nice beast but:
>
> > - 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

[Mark Lawrence]

Because there aren't enough volunteers to get it done any faster?

--
Cheers.

Mark Lawrence.

[Steven D'Aprano]

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.


--
Steven

[Dave Angel]

On 09/21/2012 11:54 AM, Steven D'Aprano wrote:
> 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.
>
>

Correct.

--

DaveA

[Steven D'Aprano]

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
>
> And it replaced C++03, released in 2003.

I stand corrected, thank you.


--
Steven

[Chris Angelico]

On Sat, Sep 22, 2012 at 1:54 AM, Steven D'Aprano
<steve+comp....@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.

ChrisA

[Steven D'Aprano]

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....@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.



--
Steven

[Chris Angelico]

On Sat, Sep 22, 2012 at 11:43 AM, Steven D'Aprano

<steve+comp....@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....@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. :)

ChrisA

[alex23]

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.

[Terry Reedy]

Batteries are batteries, not flashlights, phone, radios, toys, clickers,
etc.

--
Terry Jan Reedy

[alex23]

On Sep 24, 2:29 pm, Terry Reedy <tjre...@udel.edu> wrote:
> Batteries are batteries, not flashlights, phone, radios, toys, clickers,
> etc.

I decided not to mention "venv" as it undermines my rant a little :)

[Ramchandra Apte]

Do remember to include laptops.

[Ramchandra Apte]

On Monday, 24 September 2012 09:59:12 UTC+5:30, Terry Reedy wrote:

[88888 Dihedral]

xliiv於 2012年9月21日星期五UTC+8下午9時13分38秒寫道：

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.

[88888 Dihedral]

xliiv於 2012年9月21日星期五UTC+8下午9時13分38秒寫道：