On 2/02/20 1:00 AM, R.Wieser wrote:
As sent to the OP. I appreciate these discussions, in the expectation of
learning something-new. (and with rust-removal paints at the ready!)
Indeed. Even if its just a different POV which makes you rethink the
reasons of your own one.
+1
--
Regards =dn
DL,
>> While I agree with you there, I've been searching for other ways to
>> detect a
>> keypress (in a console-based script) and have found none.
>
> Color me disappointed!
I was disapponted too, but realized that being able to just capture any
keypress (how does the 'puter know the sc
On 2020-01-30 07:56:30 +1100, Chris Angelico wrote:
> On Thu, Jan 30, 2020 at 7:49 AM MRAB wrote:
> > On 2020-01-29 20:00, jkn wrote:
> > > I could have a file with all the URLs listed and work through each line
> > > in turn.
> > > But then I would have to rewrite the file (say, with the
> > >
On Sat, Feb 1, 2020 at 4:17 PM DL Neil via Python-list
wrote:
>
> On 31/01/20 9:53 PM, R.Wieser wrote:
> >> Using ctrl+c is a VERY BAD idea.
> >
> > To have it just exit the program ? Yes, indeed.
> >
> > Though you /could/ keep track of what needs to be finished and have the
> > ctrl-c handler d
On 31/01/20 9:53 PM, R.Wieser wrote:
Using ctrl+c is a VERY BAD idea.
To have it just exit the program ? Yes, indeed.
Though you /could/ keep track of what needs to be finished and have the
ctrl-c handler do that for you (barf).
Another posibility is to capture the ctrl-c and set a flag, whi
On 31/01/20 9:30 AM, jkn wrote:
Err, well, thanks for that discussion gents...
As it happens I do know how to use a database, but I regard it as overkill for
what I am trying to do here. I think a combination of hashing the URL,
and using a suffix to indicate the result of previous downloaded at
jkn,
> I'm happy to consider the risk and choose (eg.) the hash function
> accordingly, thanks.
No problem, just wanted you to be aware and (thus) able to choose.
Regards,
Rudy Wieser
--
https://mail.python.org/mailman/listinfo/python-list
On Friday, January 31, 2020 at 9:41:32 AM UTC, R.Wieser wrote:
> jkn,
>
> > I think a combination of hashing the URL,
>
> I hope you're not thinking of saving the hash (into the "done" list) instead
> if the URL itself. While hash collisions do not happen often (especially
> not in a small li
On Friday, January 31, 2020 at 9:41:32 AM UTC, R.Wieser wrote:
> jkn,
>
> > I think a combination of hashing the URL,
>
> I hope you're not thinking of saving the hash (into the "done" list) instead
> if the URL itself. While hash collisions do not happen often (especially
> not in a small li
jkn,
> I think a combination of hashing the URL,
I hope you're not thinking of saving the hash (into the "done" list) instead
if the URL itself. While hash collisions do not happen often (especially
not in a small list), you cannot rule them out. And when that happens that
would mean you wo
On Fri, Jan 31, 2020 at 7:56 PM R.Wieser wrote:
>
> Dennis,
>
> > A full client/server RDBM should never be affected by an abort
> > of a client program.
>
> What you describe is on the single query level. What I was thinking of was
> having several queries that /should/ work as a single unit, b
DL,
>> Nothing that can't be countered by keeping copies of the last X number of
>> to-be-dowloaded-URLs files.
>
> That's a good idea, but how would the automated system 'know' to give-up
> on the current file and utilise generation n-1? Unable to open the file or
> ???
Well, that would be one r
Dennis,
> A full client/server RDBM should never be affected by an abort
> of a client program.
What you describe is on the single query level. What I was thinking of was
having several queries that /should/ work as a single unit, but could get
interrupted (because of the OPs ctrl-c).
Yes, C
On 30/01/20 9:35 PM, R.Wieser wrote:
MRAB's scheme does have the disadvantages to me that Chris has pointed
out.
Nothing that can't be countered by keeping copies of the last X number of
to-be-dowloaded-URLs files.
That's a good idea, but how would the automated system 'know' to give-up
on th
Err, well, thanks for that discussion gents...
As it happens I do know how to use a database, but I regard it as overkill for
what I am trying to do here. I think a combination of hashing the URL,
and using a suffix to indicate the result of previous downloaded attempts, will
work adequately for m
On Fri, Jan 31, 2020 at 4:11 AM R.Wieser wrote:
> But, do you remember what the OP said ?
> [quote]
> want to download these as a 'background task'. ... you can CTRL-C out,
> [/quote]
>
> Why now do I think that, when such a backgroud process is forgotten and the
> 'puter switched off, the file, d
Chris,
> Yes, and then you backpedalled furiously when I showed that
> proper transactions prevent this.
You're a fool, out for a fight.
/You/ might know exactly how to handle a database to make sure its
/transactions/ will not leave the database in a corrupt state, but as I
mentioned a few po
On Fri, Jan 31, 2020 at 2:01 AM R.Wieser wrote:
>
> Chris,
>
> >> I think that a database is /definitily/ overcomplicating stuff,
> >
> > Okay, sure... but you didn't say that.
>
> I'm sorry ? In my first reply I described a file-based approach and
> mentioned that the folder approach is a rathe
Chris,
>> I think that a database is /definitily/ overcomplicating stuff,
>
> Okay, sure... but you didn't say that.
I'm sorry ? In my first reply I described a file-based approach and
mentioned that the folder approach is a rather good one. What do you think
I ment there ?
> You said that
On Thu, 30 Jan 2020 23:34:59 +1100
Chris Angelico wrote:
> ... I wasn't advocating for the use of a database; my first and
> strongest recommendation was, and still is, a stateless system wherein
> the files themselves are the entire indication of which documents have
> been downloaded.
Yes, I l
On Thu, Jan 30, 2020 at 11:11 PM R.Wieser wrote:
>
> Chris,
>
> > That's what transactions are for.
>
> Again,
>
> >> I guess that that went right over your head. :-)/You/ might know
> >> exactly
> >> what should and shouldn't be done, what makes you think the OP currently
> >> does ?
>
> > I
Chris,
> That's what transactions are for.
Again,
>> I guess that that went right over your head. :-)/You/ might know
>> exactly
>> what should and shouldn't be done, what makes you think the OP currently
>> does ?
> I don't understand why you're denigrating databases,
Am I denigrating a
On Thu, Jan 30, 2020 at 8:36 PM R.Wieser wrote:
>
> Chris,
>
> > Uhh
> >
> > Proper databases don't HAVE non-atomic operations. That's kinda their job.
>
> Uhh... yes, /singular/ operations are considered to be atomic. A series of
> operations /ment/ to be executed as a single one on the oth
Chris,
> Uhh
>
> Proper databases don't HAVE non-atomic operations. That's kinda their job.
Uhh... yes, /singular/ operations are considered to be atomic. A series of
operations /ment/ to be executed as a single one on the other hand aren't.
> Unless you mean that there's a non-atomic ope
On Thu, Jan 30, 2020 at 7:41 PM R.Wieser wrote:
> Also think of the old adagio:
BTW, the word you want here is "adage", unless you mean that it's a
piece of music being played slowly :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Jan 30, 2020 at 7:41 PM R.Wieser wrote:
> A database /sounds/ good, but what happens when you ctrl-c outof a
> non-atomic operation ? How do you fix that ?IOW: Databases can be
> corrupted for pretty-much the same reason as for a simple datafile (but with
> much worse consequences).
jkn,
> MRAB's scheme does have the disadvantages to me that Chris has pointed
> out.
Nothing that can't be countered by keeping copies of the last X number of
to-be-dowloaded-URLs files.
As for rewriting every time, you will /have/ to write something for every
action (and flush the file!), if
On Thu, Jan 30, 2020 at 8:59 AM DL Neil via Python-list
wrote:
> * NB I don't use SQLite (in favor of going 'full-fat') and thus cannot
> vouch for its behavior under load/queuing mechanism/concurrent
> accesses... but I'm biased and probably think/write SQL more readily
> than Python - oops!
I d
On 30/01/20 10:38 AM, jkn wrote:
On Wednesday, January 29, 2020 at 8:27:03 PM UTC, Chris Angelico wrote:
On Thu, Jan 30, 2020 at 7:06 AM jkn wrote:
I want to be a able to use a simple 'download manager' which I was going to
write
(in Python), but then wondered if there was something suitable
On Wednesday, January 29, 2020 at 8:27:03 PM UTC, Chris Angelico wrote:
> On Thu, Jan 30, 2020 at 7:06 AM jkn wrote:
> >
> > Hi all
> > I'm almost embarrassed to ask this as it's "so simple", but thought I'd
> > give
> > it a go...
>
> Hey, nothing wrong with that!
>
> > I want to be a able
On Thu, 30 Jan 2020 07:26:36 +1100
Chris Angelico wrote:
> On Thu, Jan 30, 2020 at 7:06 AM jkn wrote:
> > The situation is this - I have a long list of file URLs and want to
> > download these as a 'background task'. I want this to process to be
> > 'crudely persistent' - you can CTRL-C out, an
On Thu, Jan 30, 2020 at 7:49 AM MRAB wrote:
>
> On 2020-01-29 20:00, jkn wrote:
> > I could have a file with all the URLs listed and work through each line in
> > turn.
> > But then I would have to rewrite the file (say, with the
> > previously-successful
> > lines commented out) as I go.
> >
>
On 2020-01-29 20:00, jkn wrote:
Hi all
I'm almost embarrassed to ask this as it's "so simple", but thought I'd
give
it a go...
I want to be a able to use a simple 'download manager' which I was going to
write
(in Python), but then wondered if there was something suitable already out
ther
On Thu, Jan 30, 2020 at 7:06 AM jkn wrote:
>
> Hi all
> I'm almost embarrassed to ask this as it's "so simple", but thought I'd
> give
> it a go...
Hey, nothing wrong with that!
> I want to be a able to use a simple 'download manager' which I was going to
> write
> (in Python), but then wo
Hi all
I'm almost embarrassed to ask this as it's "so simple", but thought I'd give
it a go...
I want to be a able to use a simple 'download manager' which I was going to
write
(in Python), but then wondered if there was something suitable already out
there.
I haven't found it, but thought p
On 2018-03-25, Steven D'Aprano wrote:
> Not really. With multiple CPUs, you have the option of running two
> distinct OSes in isolation, not merely virtual machines but actual
> distinct machines in the same box.
Not on any of the multi-CPU motherboards I ever worked with. The CPUs
shared SDR
On 2018-03-25 22:52:59 +, Steven D'Aprano wrote:
> On Sun, 25 Mar 2018 23:29:07 +0200, Peter J. Holzer wrote:
> >> >> By the way, multiple CPU machines are different from CPUs with
> >> >> multiple cores:
> >> >>
> >> >> http://smallbusiness.chron.com/multiple-cpu-vs-multicore-33195.html
> >> >
amazing !
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
On Fri, 6 Apr 2018, 15:52 Steven D'Aprano, <
steve+comp.lang.pyt...@pearwood.info> wrote:
> I stumbled across this post from the Timbot, Tim Peters, back in 2000,
> where he correctly predicted that Python would get generators
I stumbled across this post from the Timbot, Tim Peters, back in 2000,
where he correctly predicted that Python would get generators and
iterators in Python 2:
https://mail.python.org/pipermail/python-list/2000-January/033955.html
as well as list comprehensions.
--
Steve
--
https://mail.py
On Monday 26 March 2018 12:12:46 Dennis Lee Bieber wrote:
> On Mon, 26 Mar 2018 11:30:54 -0400, Gene Heskett
>
>
> declaimed the following:
> >On Monday 26 March 2018 10:06:36 Dennis Lee Bieber wrote:
>
>
>
> >>As I recall, the bootloader on the Raspberry Pi runs on the
> >> graphics p
On Monday 26 March 2018 10:06:36 Dennis Lee Bieber wrote:
> On Mon, 26 Mar 2018 10:02:15 + (UTC), Steven D'Aprano
>
> declaimed the following:
> >Hardware people can probably tell you what it is that CPUs do that
> > FPUs and GPUs don't do. Or specialised Bitcoin mining chips.
> > Whatever it
On Mon, 26 Mar 2018 10:03:43 +1100, Chris Angelico wrote:
> At what point does it change from being two CPUs to being one CPU and
> one auxiliary processing unit?
When someone writes an OS that will run on the "auxiliary processing
unit" alone, then it's probably time to start calling it a CPU :
On Mon, Mar 26, 2018 at 9:52 AM, Steven D'Aprano
wrote:
> On Sun, 25 Mar 2018 23:29:07 +0200, Peter J. Holzer wrote:
>
> [...]
>>> >> By the way, multiple CPU machines are different from CPUs with
>>> >> multiple cores:
>>> >>
>>> >> http://smallbusiness.chron.com/multiple-cpu-vs-multicore-33195.h
On Sun, 25 Mar 2018 23:29:07 +0200, Peter J. Holzer wrote:
[...]
>> >> By the way, multiple CPU machines are different from CPUs with
>> >> multiple cores:
>> >>
>> >> http://smallbusiness.chron.com/multiple-cpu-vs-multicore-33195.html
>> >
>> > Yeah, it was always "multiple CPUs", not "multiple
On 2018-02-19 12:39:51 +0100, Adriaan Renting wrote:
> >>> On 17-2-2018 at 22:02, in message
> ,
> Chris Angelico wrote:
> > On Sun, Feb 18, 2018 at 5:05 AM, Steven D'Aprano
> > wrote:
> >> If you're talking about common desktop computers, I think you're
> >> forgetting how recent multicore mach
One is the BDFL
http://www.computerhistory.org/press/2018-fellow-honorees.html
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
er threads from
running.
>>> Also, Python has existed for multiple CPU systems pretty much since
its
>>> inception, I believe. (Summoning the D'Aprano for history lesson?)
>>
>> If you're talking about common desktop computers, I think you're
>>
On Mon, Feb 19, 2018 at 10:39 PM, Adriaan Renting wrote:
> I remember running 2 Mendocino 300 MHz Celerons on a Pentium II Xeon
> motherboard to get a
> multi-cpu machine for running multiple virtual machines for testing
> purposes around 1998.
> This was not as Intel intended, but a quite cheap c
We’ve made a small change to the PEP process which may affect readers of
python-list and python-ideas, so I’d like to inform you of it. This change was
made to PEP 1 and PEP 12.
PEPs must have a Post-History header which records the dates at which the PEP
is posted to mailing lists, in order
http://www.snarky.ca/the-history-behind-the-decision-to-move-python-to-github
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
https://www.youtube.com/watch?v=M9ebkjWU6Z4
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Sep 14, 2015 at 3:55 AM, Laura Creighton wrote:
> It definitely was with replying to me with the regular, not browser
> app. I will be overjoyed to hear that gmail respects text-only
>
> Thread stats here:
> https://mail.python.org/pipermail/python-list/2015-July/694572.html
>
> On the ot
On 14 September 2015 at 09:24, Chris Angelico wrote:
> On Mon, Sep 14, 2015 at 6:01 PM, Laura Creighton wrote:
>> Since you are a gmail user, you should be able to see this:
>>
> import sys
> import os
> import tkinter
> from __future__ import print_function
> for i in range(3
In a message of Mon, 14 Sep 2015 18:24:42 +1000, Chris Angelico writes:
>On Mon, Sep 14, 2015 at 6:01 PM, Laura Creighton wrote:
>> Since you are a gmail user, you should be able to see this:
>>
> import sys
> import os
> import tkinter
> from __future__ import print_function
>
On Mon, Sep 14, 2015 at 6:01 PM, Laura Creighton wrote:
> Since you are a gmail user, you should be able to see this:
>
import sys
import os
import tkinter
from __future__ import print_function
for i in range(3):
> ... print (i)
> ...
> 0
> 1
> 2
>
> Now try to reply t
In a message of Sun, 13 Sep 2015 23:35:01 +0200, Glus Xof writes:
>If I'm not wrong, in a later interpreter versions, when an enter key was
>pressed after writing something requiring some indentated statement(s)...
>like in:
>
for i in range (0,3):
>
>the system used to suggest "one tab" placi
compile the sources
> >(in Debian GNU/Linux platfom) in order to the arrow keys emit the history
> >commands instead of... it seems that escape sequences...
> >
> >Python 3.5.0 (default, Sep 13 2015, 17:58:38)
> >[GCC 4.9.2] on linux
> >Type "help", &quo
On 9/13/2015 1:15 PM, Glus Xof wrote:
Is yet an automatic indentation system implemented ?
The Idle editor does pep8-aware 'smart indenting'. In the following,
'|' indicates the cursor position after is pressed.
A ':' at the end of the line adds 1 indent -- unless there is an opener
that h
w keys emit the history
>commands instead of... it seems that escape sequences...
>
>Python 3.5.0 (default, Sep 13 2015, 17:58:38)
>[GCC 4.9.2] on linux
>Type "help", "copyright", "credits" or "license" for more information.
>>>> ^[[A^[[A^
Hi guys,
Today, a new python stable version was released (thanks for your job)...
and I write to ask you for the recommended method to compile the sources
(in Debian GNU/Linux platfom) in order to the arrow keys emit the history
commands instead of... it seems that escape sequences...
Python
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
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
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
able 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
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 Sat, Nov 22, 2014 at 11:37 AM, Ben Finney 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 paths makes this portab
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
Chris Angelico 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 the
module.
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
1 - 100 of 385 matches
Mail list logo
