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
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;
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
--
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
--
Rick Johnson rantingrickjohn...@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
--
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
On Nov 23, 2014 4:41 PM, Gregory Ewing greg.ew...@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
On Mon, Nov 24, 2014 at 3:23 AM, Dennis Lee Bieber
wlfr...@ix.netcom.com wrote:
On Sun, 23 Nov 2014 18:43:40 +1100, Ben Finney ben+pyt...@benfinney.id.au
declaimed the following:
PostgreSQL is a full-blown system that is itself under continual
development, and its APIs continually change to
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
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
On Mon, Nov 24, 2014 at 5:25 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
The migrant/state symbiosis is a fine example of how we (as
*weak* emotional beings) fall into these emotional traps
set by forked tongued propagandist in hopes of diverting
our attention away from reality. No
On Fri, Nov 21, 2014 at 6:07 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Friday, November 21, 2014 5:59:44 PM UTC-6, Chris Angelico wrote:
In other words, what you want is:
# today's method, import based on search path
import sys
# new explicit path method
import
Ian Kelly wrote:
On Thu, Nov 20, 2014 at 8:53 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
FOR INSTANCE: Let's say i write a module that presents a
reusable GUI calendar widget, and then i name the module
calender.py.
Then Later, when i try to import *MY* GUI widget named
On Sat, Nov 22, 2014 at 11:25 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Ian Kelly wrote:
- It's hard to keep track of what modules are in the standard library. Which
of the following is *not* in Python 3.3's std lib? No cheating by looking
them up.)
os2emxpath,
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
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.
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
Chris Angelico wrote:
On Sat, Nov 22, 2014 at 11:25 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Ian Kelly wrote:
- It's hard to keep track of what modules are in the standard library.
Which of the following is *not* in Python 3.3's std lib? No cheating by
looking them
On Sunday, November 23, 2014 12:00:15 PM UTC+5:30, Steven D'Aprano wrote:
Rick should ask himself why virtually every single language, from compiled
languages like Ada, C, Pascal and Java, to interpreted languages like bash,
all use search paths instead of explicit paths.
Hint: the answer is
On Sun, Nov 23, 2014 at 5:30 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Chris Angelico wrote:
Okay, here's my guesses.
os2emxpath: In the stdlib, but more often accessed as os.path while
running under OS/2
Correct.
I'm in a special position here, as I actually have an
On Sun, Nov 23, 2014 at 5:30 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
wave: Not in the stdlib, though I'd avoid the name anyway.
Incorrect. The wave module is for manipulating .wav files.
sndheader: Not in the stdlib - probably on PyPI though
Correct. It is actually
Chris Angelico ros...@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
On Sun, Nov 23, 2014 at 6:43 PM, Ben Finney ben+pyt...@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
On 2014-11-20 19:53, Rick Johnson wrote:
FOR INSTANCE: Let's say i write a module that presents a
reusable GUI calendar widget, and then i name the module
calender.py.
Then Later, when i try to import *MY* GUI widget named
calendar, i will not get *MY* calendar widget, no, i will
get the
On 11/20/14 10:53 PM, Rick Johnson wrote:
If you had taken the time to read
my example utilizing a lobby boy, then you might have
understood what i was talking about.
Rick, if you are frustrated that people don't know what you are talking
about, you should try writing shorter messages, with
On Thu, Nov 20, 2014 at 8:53 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
FOR INSTANCE: Let's say i write a module that presents a
reusable GUI calendar widget, and then i name the module
calender.py.
Then Later, when i try to import *MY* GUI widget named
calendar, i will not get
On Friday, November 21, 2014 4:29:48 AM UTC-6, Tim Chase wrote:
What messed-up version of Python are you running?
Or did you fail to test your conjecture?
$ cat calendar.py
print(This is my local calendar.py)
x=1
$ cat importtest.py
import calendar
print(dir(calendar))
$ python2
On 2014-11-21 07:52, Rick Johnson wrote:
On Friday, November 21, 2014 4:29:48 AM UTC-6, Tim Chase wrote:
What messed-up version of Python are you running?
Or did you fail to test your conjecture?
$ cat calendar.py
print(This is my local calendar.py)
x=1
$ cat importtest.py
On Fri, Nov 21, 2014 at 9:12 AM, Tim Chase
python.l...@tim.thechases.com wrote:
The only time I've been stung by name overloading is in the indirect
case of creating a local email.py file and then importing smtplib
only to have things break in unforeseen ways. If smtplib used
relative imports
On Friday, November 21, 2014 9:34:55 AM UTC-6, Ian wrote:
On Thu, Nov 20, 2014 at 8:53 PM, Rick Johnson
FOR INSTANCE: Let's say i write a module that presents a
reusable GUI calendar widget, and then i name the module
calender.py.
Then Later, when i try to import *MY* GUI widget named
On Sat, Nov 22, 2014 at 5:24 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
Of course, I did that a long time ago! But like everything
in Python, when your try to be cleaver...
Just so you know, I never try to be one of these.
On 11/21/2014 11:24 AM, Rick Johnson wrote:
Why am *i* the fool when it's obvious that
the creators of Python were either shortsighted and/or
careless with the designs? The only people who suffer are
those who put their trust in the designer, and not the
designer himself -- something is wrong
On Fri, Nov 21, 2014 at 11:24 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
Are you also going to call drivers fools because they bought
a certain brand of car only to have the airbag explode in
their face?
No, but I'll call them fools if they buy a car and the engine catches
fire
On Friday, November 21, 2014 1:06:18 PM UTC-6, Michael Torrie wrote:
On 11/21/2014 11:24 AM, Rick Johnson wrote:
Why am *i* the fool when it's obvious that
the creators of Python were either shortsighted and/or
careless with the designs? The only people who suffer are
those who put their
On Friday, November 21, 2014 1:24:53 PM UTC-6, Ian wrote:
On Fri, Nov 21, 2014 at 11:24 AM, Rick Johnson
Are you also going to call drivers fools because they bought
a certain brand of car only to have the airbag explode in
their face?
No, but I'll call them fools if they buy a car and
On 11/21/2014 01:29 PM, Rick Johnson wrote:
Not personally. But how will we *ever* know if he refuses to
participate in these discussions?
Why should he participate in these discussions? Why should you be in
charge of said discussions?
By the way, Python has more than certainly borne fruit,
On Friday, November 21, 2014 4:25:49 PM UTC-6, Rick Johnson wrote:
# STEP 3 #
# Make the following changes to the import
On Sat, Nov 22, 2014 at 10:21 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
1. Use the historical implicit import mechanism for most day
to day imports, and let Python do all the heavy lifting.
2. Use the new explicit import mechanism for advanced name
resolutions, but realize that
On Fri, Nov 21, 2014 at 3:25 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
The only exception is if you're doing import calendar from inside
the ricklib package, and you're using Python 2, and you don't have
from __future__ import absolute_import at the top of your module.
The solution
On Friday, November 21, 2014 3:21:31 PM UTC-8, Rick Johnson wrote:
On Friday, November 21, 2014 4:25:49 PM UTC-6, Rick Johnson wrote:
# STEP 3 #
Chris Angelico ros...@gmail.com writes:
In other words, what you want is:
# today's method, import based on search path
import sys
# new explicit path method
import '/usr/local/lib/python3.5/lib-dynload/math.cpython-35m.so'
I don't think I'd ever want to specify an absolute file path for
On Friday, November 21, 2014 5:59:44 PM UTC-6, Chris Angelico wrote:
On Sat, Nov 22, 2014 at 10:21 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
1. Use the historical implicit import mechanism for most day
to day imports, and let Python do all the heavy lifting.
2. Use the new
On Friday, November 21, 2014 6:33:32 PM UTC-6, Ian wrote:
On Fri, Nov 21, 2014 at 3:25 PM, Rick Johnson
Why does the code in the main package need to run when i
*explicitly* and *directly* fetched a nested resource
within the package?[...]
It has nothing to do with the __init__ file
On Sat, Nov 22, 2014 at 11:37 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
I don't think I'd ever want to specify an absolute file path for the
module. But it would make my Python life immeasurably better if I could
specify *relative* file paths for importing a module.
Allowing relative
On Sat, Nov 22, 2014 at 12:07 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Friday, November 21, 2014 5:59:44 PM UTC-6, Chris Angelico wrote:
On Sat, Nov 22, 2014 at 10:21 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
1. Use the historical implicit import mechanism for most
On 16/11/2014 3:01 PM, Rick Johnson wrote:
Python's attempt to solve the external dependencies problem
has yet to produce the results that many people, including
myself, would like.
I'd say this was an argumentum ad populum, only you didn't cite anything
that shows the many you claim you
On Fri, Nov 21, 2014 at 11:14 AM, alex23 wuwe...@gmail.com wrote:
1. Name clashes!
2. Smaller name pool!
Just off the top of my head, we have several solutions for this:
1) Rebinding imports
import foo as foo2
To be fair to Rick, this doesn't actually solve anything. If you
On Thursday, November 20, 2014 6:15:03 PM UTC-6, alex23 wrote:
On 16/11/2014 3:01 PM, Rick Johnson wrote:
[...]
Actually, Python is not alone in this deficiency, no, Python
is just *ANOTHER* language in a *STRING* of languages over
the years who has *YET AGAIN* implemented the same old
Python's attempt to solve the external dependencies problem
has yet to produce the results that many people, including
myself, would like.
Actually, Python is not alone in this deficiency, no, Python
is just *ANOTHER* language in a *STRING* of languages over
the years who has *YET AGAIN*
On Sun, Nov 16, 2014 at 4:01 PM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
Creating an implicit name resolution system (aka: import)
to abstract away an explicit name resolution system
(file-paths) has resulted in more problems that it can solve:
1. Name clashes!
2. Smaller
50 matches
Mail list logo
