On Nov 23, 2014 4:41 PM, "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 w
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 Sto
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?
Marko
--
https://mail.python.org/mailman/listinfo/
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
--
http
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
--
https://mail.python.org/mailman/listinfo/python
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 KEEPE
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 suspe
On Mon, Nov 24, 2014 at 5:25 PM, Rick Johnson
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 being in this universe
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
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
On Mon, Nov 24, 2014 at 3:23 AM, Dennis Lee Bieber
wrote:
> On Sun, 23 Nov 2014 18:43:40 +1100, Ben Finney
> 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 Postg
On Sun, Nov 23, 2014 at 6:43 PM, Ben Finney 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
Chris Angelico 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 diffe
On Sun, Nov 23, 2014 at 5:30 PM, Steven D'Aprano
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 spelled "sndhdr".
Just out
On Sun, Nov 23, 2014 at 5:30 PM, Steven D'Aprano
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 OS/2 system, and
have
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 answe
Chris Angelico wrote:
> On Sat, Nov 22, 2014 at 11:25 PM, Steven D'Aprano
> 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-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
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 mycale
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 yo
On Sat, Nov 22, 2014 at 11:25 PM, Steven D'Aprano
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, wave, sndheader, statslib, poplis
Ian Kelly wrote:
> On Thu, Nov 20, 2014 at 8:53 PM, 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 no
On Fri, Nov 21, 2014 at 6:07 PM, Rick Johnson
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 '/usr/local/lib/python3.5/lib-d
On Sat, Nov 22, 2014 at 12:07 PM, Rick Johnson
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
>> wrote:
>> > 1. Use the historical "implicit import" mechanism for most day
>> > to day imports, and let Python do all t
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__
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
> 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" me
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 #
> > #
On Fri, Nov 21, 2014 at 3:25 PM, Rick Johnson
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 to this is easy:
On Sat, Nov 22, 2014 at 10:21 AM, Rick Johnson
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 since you are now takin
On Friday, November 21, 2014 4:25:49 PM UTC-6, Rick Johnson wrote:
>
> # STEP 3 #
>
> # Make the following changes to the impor
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 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
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 pu
On Fri, Nov 21, 2014 at 11:24 AM, Rick Johnson
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 because they never bothered
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 w
On Sat, Nov 22, 2014 at 5:24 AM, Rick Johnson
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.
http://img1.wikia.nocookie.net/__cb20110615074214/americanmcgeesalice/images/1/1a/Vorpal
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 wi
On Fri, Nov 21, 2014 at 9:12 AM, Tim Chase
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 for $STDLIB/email.py I su
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
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))
>
On Thu, Nov 20, 2014 at 8:53 PM, 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,
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 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
>
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
On Fri, Nov 21, 2014 at 11:14 AM, alex23 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 have
two
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 s
On Sun, Nov 16, 2014 at 4:01 PM, Rick Johnson
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 name pool!
> 3. M
47 matches
Mail list logo
