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é]

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.

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

 

[xliiv]

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.
- about readme and manifest.in:
"You could add to your template a file called readme.rst . Inside of it youcan 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]

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.
- about readme and manifest.in:
"You could add to your template a file called readme.rst . Inside of it youcan 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..

 

[Tarek Ziadé]

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]

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]

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'?

 

[Mark Lawrence]

Why is this '2 years release cycle'?

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

 

[Steven D'Aprano]

On 21/09/2012 14:13, xliiv wrote:
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.

 

[Dave Angel]

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.

 

[Steven D'Aprano]

On 09/21/2012 11:54 AM, Steven D'Aprano wrote:

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

 

[Chris Angelico]

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

 

[Dennis Lee Bieber]

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

Before my lay-off I'd been tasked to examine a version complication
on systems at work.

I'd produced a few scripts under Python 2.3... They /should/ be
workable under any later 2.x version (the only externals were [at the
time] ctypes, PMW, and maybe one other library). BUT -- out of fear the
organization kept installing 2.3 [and its a good thing I'd kept a CD of
my original installation disk for the scripts].

Problem -- one system had a script written by someone else that used
Python 2.2 AND had a custom binary DLL. My scripts couldn't be
downgraded to 2.2 as they /did/ rely on features new in 2.3.

And I couldn't find the source code for that custom DLL to enable
building for a newer Python. Don't know if they ever tracked down the
author of that program to find out how to upgrade it.

Sole reason they needed this unification? They were adding that 2.2
system to the ClearCase controlled network -- and my 2.3 scripts were
the ones that automated the loading of specified "builds" from ClearCase
onto the runtime hardware.

 

[Steven D'Aprano]

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.

 

[Chris Angelico]

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.

But not faster than ≈18 months between minor releases. Not unlessyou
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]

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]

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.


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.

 

[alex23]

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]

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

etc.

Do remember to include laptops.

 

[Ramchandra Apte]

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

etc.

Do remember to include laptops.