Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #80850 > unrolled thread

PyWart: "Python's import statement and the history of external dependencies"

Back to article view | Back to comp.lang.python

Contents

  PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-15 21:01 -0800
    Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-16 16:16 +1100
    Re: PyWart: "Python's import statement and the history of external dependencies" alex23 <wuwei23@gmail.com> - 2014-11-21 10:14 +1000
      Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-21 11:31 +1100
      Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-20 19:53 -0800
        Re: PyWart: "Python's import statement and the history of external dependencies" Tim Chase <python.list@tim.thechases.com> - 2014-11-21 04:26 -0600
          Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-21 07:52 -0800
            Re: PyWart: "Python's import statement and the history of external dependencies" Tim Chase <python.list@tim.thechases.com> - 2014-11-21 10:12 -0600
            Re: PyWart: "Python's import statement and the history of external dependencies" Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-21 10:42 -0700
        Re: PyWart: "Python's import statement and the history of external dependencies" Ned Batchelder <ned@nedbatchelder.com> - 2014-11-21 06:32 -0500
        Re: PyWart: "Python's import statement and the history of external dependencies" Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-21 08:33 -0700
          Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-21 10:24 -0800
            Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-22 05:34 +1100
            Re: PyWart: "Python's import statement and the history of external dependencies" Michael Torrie <torriem@gmail.com> - 2014-11-21 12:05 -0700
              Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-21 12:29 -0800
                Re: PyWart: "Python's import statement and the history of external dependencies" Michael Torrie <torriem@gmail.com> - 2014-11-21 15:54 -0700
            Re: PyWart: "Python's import statement and the history of external dependencies" Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-21 12:23 -0700
              Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-21 14:25 -0800
                Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-21 15:21 -0800
                  Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-22 10:52 +1100
                    Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-21 17:07 -0800
                      Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-22 13:36 +1100
                      Re: PyWart: "Python's import statement and the history of external dependencies" Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-22 02:27 -0700
                  Re: PyWart: "Python's import statement and the history of external dependencies" sohcahtoa82@gmail.com - 2014-11-21 16:33 -0800
                  Import a module from a specific file path (was: PyWart: "Python's import statement and the history of external dependencies") Ben Finney <ben+python@benfinney.id.au> - 2014-11-22 11:37 +1100
                    Re: Import a module from a specific file path Marko Rauhamaa <marko@pacujo.net> - 2014-11-22 08:28 +0200
                  Re: Import a module from a specific file path (was: PyWart: "Python's import statement and the history of external dependencies") Chris Angelico <rosuav@gmail.com> - 2014-11-22 13:32 +1100
                  Re: Import a module from a specific file path Ben Finney <ben+python@benfinney.id.au> - 2014-11-22 17:46 +1100
                Re: PyWart: "Python's import statement and the history of external dependencies" Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-21 17:32 -0700
                  Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-21 17:48 -0800
            Re: PyWart: "Python's import statement and the history of external dependencies" Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-11-21 15:38 -0500
          Re: PyWart: "Python's import statement and the history of external dependencies" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-22 23:25 +1100
            Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-23 00:00 +1100
              Re: PyWart: "Python's import statement and the history of external dependencies" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-23 17:30 +1100
                Re: PyWart: "Python's import statement and the history of external dependencies" Rustom Mody <rustompmody@gmail.com> - 2014-11-22 22:44 -0800
                Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-23 17:56 +1100
                Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-23 17:59 +1100
                  Re: PyWart: "Python's import statement and the history of external   dependencies" Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-11-24 11:37 +1300
                    Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-23 22:25 -0800
                      Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-24 17:34 +1100
                      Re: PyWart: "Python's import statement and the history of external dependencies" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-11-24 10:34 +0000
                        Re: PyWart: "Python's import statement and the history of external dependencies" Rick Johnson <rantingrickjohnson@gmail.com> - 2014-11-24 08:51 -0800
                          Re: PyWart: "Python's import statement and the history of external dependencies" Ned Batchelder <ned@nedbatchelder.com> - 2014-11-24 12:06 -0500
                          Re: PyWart: "Python's import statement and the history of external dependencies" Robin Becker <robin@reportlab.com> - 2014-11-24 17:07 +0000
                          Re: PyWart: "Python's import statement and the history of external dependencies" Marko Rauhamaa <marko@pacujo.net> - 2014-11-24 19:08 +0200
                            Re: PyWart: "Python's import statement and the history of external dependencies" Rustom Mody <rustompmody@gmail.com> - 2014-11-24 09:38 -0800
                    Re: PyWart: "Python's import statement and the history of external dependencies" Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-24 15:34 -0700
                Re: PyWart: "Python's import statement and the history of external dependencies" Ben Finney <ben+python@benfinney.id.au> - 2014-11-23 18:43 +1100
                Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-23 18:51 +1100
                Re: PyWart: "Python's import statement and the history of external dependencies" Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-11-23 11:23 -0500
                Re: PyWart: "Python's import statement and the history of external dependencies" Chris Angelico <rosuav@gmail.com> - 2014-11-24 03:36 +1100
            Re: PyWart: "Python's import statement and the history of external dependencies" Tim Chase <python.list@tim.thechases.com> - 2014-11-22 15:27 -0600
              Re: PyWart: "Python's import statement and the history of external dependencies" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-23 12:00 +1100
                Re: PyWart: "Python's import statement and the history of external dependencies" Tim Chase <python.list@tim.thechases.com> - 2014-11-22 19:33 -0600

Page 3 of 3 — ← Prev page 1 2 [3]

#81449

On 24/11/2014 06:25, Rick Johnson wrote:
> On Sunday, November 23, 2014 4:37:53 PM UTC-6, Gregory Ewing wrote:
>> Chris Angelico wrote:
>>> Just out of curiosity, why does the stdlib need modules
>>> for manipulating .wav and other sound files, but we have
>>> to go to PyPI to get a PostgreSQL client?
>>
>> I suspect it's mainly for historical reasons. The wave
>> module has been around since the very early days of
>> Python when the stldib was smaller and the barrier
>> to entry was lower. By today's standards, it probably
>> wouldn't make it in.
>
> Immigration policies evolve basically in the same manner.
> When a country is founded in a land which is sparsely
> populated, naturally the state will welcome any and all
> immigrants (as noted in the "New Colossus"), but as the
> population becomes more and more dense, the natural (and
> wise) reaction is to limit, or even prohibit, the influx of
> migrants.
>

The Native Americans are no doubt regretting their decision to "welcome 
any and all immigrants".  Would they have made the same decision using 
Python which obviously wouldn't have been available at that time?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#81462

On Monday, November 24, 2014 4:35:13 AM UTC-6, Mark Lawrence wrote:
> The Native Americans are no doubt regretting their
> decision to "welcome any and all immigrants".  Would they
> have made the same decision using Python which obviously
> wouldn't have been available at that time?

FINDERS KEEPERS; LOSERS WEEPERS!

Contrary to your naive interpretation of history, the native
Americans did not *welcome* anyone. The demise of the native
american society is a direct result of sins they committed
against their *OWN* evolution -- dancing mindlessly around
camp fires and worshiping spirits and rocks is the path to
evolutionary abyss! On the other hand, the Europeans
recognized the potential of the land, *seized it*, and
created the most powerful nation this world has ever seen.

EVOLUTION LOVES A WINNER!
    
This universe does not give a flying fig for your individual
delusions, nor your collective societal delusions. Religion
and spiritualism are nothing more than coping mechanisms
fostered by "emotional feeble" minds who are incapable of
facing the grim realities of their own mortality! Both have
done more harm to human evolution and happiness than almost
anything else. I'm disgusted to a member of a species for
which a vast majority of my fellows have cast aside
intelligence for the mind numbing repetitive rituals and
idol worship of "shiny things" or the "maternal comfort" of
a "father/mother figure".

WHERE'S WALDO?

Where are the monuments or the vast civilizations of the
these natives? All we have today are a few arrowheads and
some clay pots. Is "pup tenting" and "bareback horse riding"
something to aspire to?  

WHERE ARE ALL ANIMAL RIGHTS ACTIVIST?

There is reason why they are called "natives", and it has
more to do with their lack of any "levels of organization"
and less to do with their birth- right. Native Americans
were a nomadic people, and they were not a nomadic people
simply because they enjoyed hauling their houses on their
backs every three months (actually, the women did most of the
hauling)

WHERE ARE ALL THE FEMINIST?

They were nomadic because they lacked the collective
intelligence to appreciate the intrinsic value of large
centralized civilizations, and as such, they were forced to
constantly chase the food sources.

A MIND IS A TERRIBLE THING TO WASTE!

Their failure to thrive is a direct result of choosing to
utilize every muscle in the body except for the most
important muscle of all, that is, the brain. Instead of
trying to live "with the earth", they should of been trying
to "exploit it". These resources exist for human
exploitation, not simply because we have been ordained by
some benevolent creature, no, but because long ago we won the
battle of intelligence against our rivals, and the spoils of
that war are the rights to exploit this earth, and all it's
inhabitants.

TO THE VICTOR GO THE SPOILS!

The native Americans lost the battle of evolution, and as a
result, they also forfeited the rights of historical
narrative. 

HISTORY IS WRITTEN BY THE WINNERS!

So go ahead and take your children on another scouting trip,
so they can build a tee-pee and cook Indian bread, and you
can tell them *fantastical* stories about how the Indians
lived in "harmony" with the earth, and you can all sing
"Kumbaya" to the strumming sounds of a guitar.

But at some point in their lives, maybe around the time you
"shatter their innocence" with the truth about "Santa Claus" and
the "Easter Bunny", you might want to also reveal to them
the results of a societal rejection of intelligence -- lest
they grow up and become like our dear friend Mark, who is
*still* writing "letters to Santa".

ALL I WANT FOR CHRISTMAS IS TO SURROUND BY INTELLIGENT BEINGS!

[toc] | [prev] | [next] | [standalone]

#81463

On 11/24/14 11:51 AM, Rick Johnson wrote:
> ... lots of off-topic ranting ...

Everyone: as tempting as it is to respond, the best course of action 
will be to completely ignore Rick's rants.

Thanks,

-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#81464

On 24/11/2014 16:51, Rick Johnson wrote:
> EVOLUTION LOVES A WINNER!

I think evolution actually requires losers. Clearly there are more extinct 
species, peoples, languages etc etc than there are existing ones so perhaps if 
evolution 'loves' anything it 'loves' a loser.
-- 
Robin Becker

[toc] | [prev] | [next] | [standalone]

#81465

Rick Johnson <rantingrickjohnson@gmail.com>:

> FINDERS KEEPERS; LOSERS WEEPERS!
>
> Contrary to your naive interpretation of history, the native
> Americans [...]

Was this rant at least produced by a Python generator?

Where's the StopIteration exception when you need one?


Marko

[toc] | [prev] | [next] | [standalone]

#81466

On Monday, November 24, 2014 10:38:52 PM UTC+5:30, Marko Rauhamaa wrote:
> Rick Johnson :
> 
> > FINDERS KEEPERS; LOSERS WEEPERS!
> >
> > Contrary to your naive interpretation of history, the native
> > Americans [...]
> 
> Was this rant at least produced by a Python generator?
> 
> Where's the StopIteration exception when you need one?

Real culprit is Ian who just segfaulted python with an infinite generator

[toc] | [prev] | [next] | [standalone]

#81472

[Multipart message — attachments visible in raw view] — view raw

On Nov 23, 2014 4:41 PM, "Gregory Ewing" <greg.ewing@canterbury.ac.nz>
wrote:
>
> Chris Angelico wrote:
>>
>> Just out of curiosity, why does the stdlib need modules for
>> manipulating .wav and other sound files, but we have to go to PyPI to
>> get a PostgreSQL client?
>
>
> I suspect it's mainly for historical reasons. The wave
> module has been around since the very early days of
> Python when the stldib was smaller and the barrier
> to entry was lower. By today's standards, it probably
> wouldn't make it in.

Size may also be a factor. The wave module is around 300 lines of Python
code and isn't growing. The typical dbapi module is probably a bit larger.

[toc] | [prev] | [next] | [standalone]

#81342

Chris Angelico <rosuav@gmail.com> writes:

> Just out of curiosity, why does the stdlib need modules for
> manipulating .wav and other sound files, but we have to go to PyPI to
> get a PostgreSQL client? It's a queer world...

I would venture the follow two reasons, either of which is sufficient to
explain the difference:

* Modules enter the standard library only if they are judged both to be
  good quality *and* have a credible promise to continue to maintain
  them in the standard library on an ongoing basis.

  If one module has reliable maintainers offering to do the work and
  another does not, the latter will not be a candidate for inclusion in
  the Python standard library.

* Modules enter the standard library only if their feature set is stable
  enough that they can remain essentially unchanged, feature-wise, for
  many years and still be widely useful.

  For a data stream format (like WAV and other mature formats), a module
  working well today is likely to work just as well for the same purpose
  in several years's time, long enough for today's Python to go through
  its full life cycle of support.

  PostgreSQL is a full-blown system that is itself under continual
  development, and its APIs continually change to match. Whatever Python
  API for PostgreSQL gets put into the standard library today is likely
  to be obsolete long before today's version of Python gets close to
  ending support. That makes it a poor candidate for inclusion in the
  standard library.

-- 
 \       “The generation of random numbers is too important to be left |
  `\                                    to chance.” —Robert R. Coveyou |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#81343

On Sun, Nov 23, 2014 at 6:43 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>   For a data stream format (like WAV and other mature formats), a module
>   working well today is likely to work just as well for the same purpose
>   in several years's time, long enough for today's Python to go through
>   its full life cycle of support.
>
>   PostgreSQL is a full-blown system that is itself under continual
>   development, and its APIs continually change to match. Whatever Python
>   API for PostgreSQL gets put into the standard library today is likely
>   to be obsolete long before today's version of Python gets close to
>   ending support. That makes it a poor candidate for inclusion in the
>   standard library.

That makes sense, as differences go. Though if wave and sndhdr were
currently PyPI-only and someone came to python-ideas/python-dev saying
"These modules ought to be in the standard library", I doubt they'd
get a huge amount of support. Of course, since they're currently in
the stdlib, there's absolutely no reason to *remove* them, but any
similar modules are likely to stay pip-gettable rather than
autoincluded. In contrast, something like Lib/email.py is providing
functionality that heaps of Python scripts want - sending or parsing
emails is pretty common, so it makes good sense to have that in the
stdlib.

ChrisA

[toc] | [prev] | [next] | [standalone]

#81382

On Sun, 23 Nov 2014 18:43:40 +1100, Ben Finney <ben+python@benfinney.id.au>
declaimed the following:

>  PostgreSQL is a full-blown system that is itself under continual
>  development, and its APIs continually change to match. Whatever Python
>  API for PostgreSQL gets put into the standard library today is likely
>  to be obsolete long before today's version of Python gets close to
>  ending support. That makes it a poor candidate for inclusion in the
>  standard library.
>
	I'd also consider that such a module is highly dependent upon having
the related server available. If PostgreSQL access were to become a
standard module I'd argue that the library should also include MySQL,
Firebird/Interbase, M$ SQL Server, at a minimum.

	SQLite3, as a file-server database, made sense as the actual database
engine is accessed as part of the Python process when invoked -- not
something that had to be configured/administered at a system-wide level.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#81384

On Mon, Nov 24, 2014 at 3:23 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Sun, 23 Nov 2014 18:43:40 +1100, Ben Finney <ben+python@benfinney.id.au>
> declaimed the following:
>
>>  PostgreSQL is a full-blown system that is itself under continual
>>  development, and its APIs continually change to match. Whatever Python
>>  API for PostgreSQL gets put into the standard library today is likely
>>  to be obsolete long before today's version of Python gets close to
>>  ending support. That makes it a poor candidate for inclusion in the
>>  standard library.
>>
>         I'd also consider that such a module is highly dependent upon having
> the related server available. If PostgreSQL access were to become a
> standard module I'd argue that the library should also include MySQL,
> Firebird/Interbase, M$ SQL Server, at a minimum.

I don't know how many ought to be included, but definitely MySQL would
be wanted. Including clients for proprietary protocols may be
considered less important. It would also be logical to include some of
the meta-protocols, though, like ODBC.

>         SQLite3, as a file-server database, made sense as the actual database
> engine is accessed as part of the Python process when invoked -- not
> something that had to be configured/administered at a system-wide level.

This is true, and I've seen plenty of explanations as to why SQLite3
but no other database. I just found it odd that, against the exclusion
of several modules which would be of significant value to a very
common Python use-case (namely, servers (eg web) that need back-end
databases) is the inclusion of something equally specific but less
commonly useful (.WAV file manipulation). But, that's what PyPI's for.

ChrisA

[toc] | [prev] | [next] | [standalone]

#81302

On 2014-11-22 23:25, Steven D'Aprano wrote:
> Having said that, it's not fair to blame the user for shadowing
> standard library modules:
> 
> - All users start off as beginners, who may not be aware that this
> is even a possibility;

While it's one thing to explicitly shadow a module (creating your own
module named "calendar"; if you need the stdlib module, you know it
and have to rename your local one), the implicit shadowing has stung
me a number of times.  I'll unthinkingly create an "email.py" and
then need to send email so I'll import smtplib (which internally
imports stdlib's email.py but it finds my local email.py) and
everything falls over. The error messages don't make it obvious what
happened.

I've been burned enough times that I now know not to do this. But it
was certainly burned into my mind after the 3rd time it happened.

> > And after all that, it would still fail if you happened to want to
> > import both "calendar" modules into the same module.
> 
> __path__ = []
> import calendar
> __path__ = ['my/python/modules']
> import calendar as mycalendar

Hrm.  Never knew this.  Could you point me at some docs on that?
(searching for "__path__" on python.org isn't turning up much that
jumps out at me as being correlated)

-tkc

[toc] | [prev] | [next] | [standalone]

#81307

Tim Chase wrote:

> On 2014-11-22 23:25, Steven D'Aprano wrote:

>> > And after all that, it would still fail if you happened to want to
>> > import both "calendar" modules into the same module.
>> 
>> __path__ = []
>> import calendar
>> __path__ = ['my/python/modules']
>> import calendar as mycalendar
> 
> Hrm.  Never knew this.  Could you point me at some docs on that?
> (searching for "__path__" on python.org isn't turning up much that
> jumps out at me as being correlated)


You've misunderstood what I said, I was proposing it as a hypothetical
feature, not something existing. Sorry for any confusion.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#81310

On 2014-11-23 12:00, Steven D'Aprano wrote:
> >> > And after all that, it would still fail if you happened to
> >> > want to import both "calendar" modules into the same module.  
> >> 
> >> __path__ = []
> >> import calendar
> >> __path__ = ['my/python/modules']
> >> import calendar as mycalendar  
> > 
> > Hrm.  Never knew this.  Could you point me at some docs on that?
> > (searching for "__path__" on python.org isn't turning up much that
> > jumps out at me as being correlated)  
> 
> You've misunderstood what I said, I was proposing it as a
> hypothetical feature, not something existing. Sorry for any
> confusion.

Ah, thanks.  I wondered but should have tried it out to see that it
wasn't an existing feature.  I'm not sure if/when I would use such a
feature, but it was at least an interesting idea.

-tkc

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web