i've had some fun recently when i've had a chance to work
on it. i needed some kind of project that would encourage
me to learn more python. i still consider myself very new
to the language and a long ways to go (and i don't consider
the code as a great example, but it is progr
On 8/22/2019 12:12 PM, Dennis Lee Bieber wrote:
On Thu, 22 Aug 2019 15:49:28 +0200, nospam_2...@efbe.prima.de declaimed the
following:
Am 22.08.19 um 15:19 schrieb Daniel:
If i have a figure like 13247347347437x23828328382 how to make a
progress bar in tkinter that shows the time the pc
If i have a figure like 13247347347437x23828328382 how to make a
progress bar in tkinter that shows the time the pc takes to give the result?
---
Este email foi escaneado pelo Avast antivírus.
https://www.avast.com/antivirus
--
https://mail.python.org/mailman/listinfo/python-list
Am 22.08.19 um 15:19 schrieb Daniel:
> If i have a figure like 13247347347437x23828328382 how to make a
> progress bar in tkinter that shows the time the pc takes to give the
> result?
>
https://docs.python.org/3/library/tkinter.ttk.html?highlight=progressbar
--
https://mai
dieter wrote:
...
thank you for your help. :) i finally worked through
the changes needed at last.
my current package in testing PyPI is at:
https://test.pypi.org/project/ngfp/
which uses my code from:
https://salsa.debian.org/ant-guest/gfpoken-in-python
i ended up needing to
dieter wrote:
> ant writes:
>> ...
>> in order to get this far below i had to edit each
>> file and put a try: except: around each import
>> statment checking if the module could be found
>> like (as an example):
>>
>> try:
>> import config as cfg
>> except:
>> import frog.config as cfg
ant writes:
> ...
> in order to get this far below i had to edit each
> file and put a try: except: around each import
> statment checking if the module could be found
> like (as an example):
>
> try:
> import config as cfg
> except:
> import frog.config as cfg
Is "frog" the package, yo
dieter wrote:
> ant writes:
>> ant wrote:
>> ...
>>> (env) me@ant(26)~/src/test$ ngfp
>>> Traceback (most recent call last):
>>> File "/home/me/src/env/bin/ngfp", line 7, in
>>> from ngfp import main
>>> ImportError: cannot import name 'main' from 'ngfp'
>>> (/home/me/src/salsa/env/lib/pyt
ant writes:
> ant wrote:
> ...
>> (env) me@ant(26)~/src/test$ ngfp
>> Traceback (most recent call last):
>> File "/home/me/src/env/bin/ngfp", line 7, in
>> from ngfp import main
>> ImportError: cannot import name 'main' from 'ngfp'
>> (/home/me/src/salsa/env/lib/python3.7/site-packages/ngf
another directory deeper (my project has a top level
> directory with the setup.py in it and then the
> ngfp directory with the __init__.py in it which
> contains the following:
>
>=
> name = "ngfp"
>=
>
> which obviously says nothing about main
ry with the __init__.py in it which
contains the following:
=
name = "ngfp"
=
which obviously says nothing about main...
i hate being a newbie.
but at least i'm making progress. :)
ant
--
https://mail.python.org/mailman/listinfo/python-list
On Sat, Jun 2, 2018 at 9:10 AM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> if you 'break' immediately after a mutation, that isn't
>> continuing to iterate. Even though you're inside the loop, there's no
>> further action taken to process the loop, and no problem.
>
>
> Yes, but you're als
Chris Angelico wrote:
if you 'break' immediately after a mutation, that isn't
continuing to iterate. Even though you're inside the loop, there's no
further action taken to process the loop, and no problem.
Yes, but you're also not calling next() again, so no
exception would be triggered.
My po
On Thu, 31 May 2018 16:37:39 +0200, Frank Millman wrote:
[...]
> Agreed, but my gut feel, and the following example, suggest that when
> processing the last key in a dictionary while iterating over it, you
> have not yet stopped iterating.
>
d = {}
d[1] = 'one'
d[2] = 'two'
Before
"Gregory Ewing" wrote in message news:fnccd8ff3s...@mid.individual.net...
Chris Angelico wrote:
> It is an error to mutate the dictionary *and then continue to iterate
> over it*.
But if you're processing the last key, and you add one so
that it's no longer the last key, what should happen?
On Fri, Jun 1, 2018 at 4:56 PM Gregory Ewing
wrote:
> Chris Angelico wrote:
> > It is an error to mutate the dictionary *and then continue to iterate
> over it*.
>
> But if you're processing the last key, and you add one so
> that it's no longer the last key, what should happen?
>
> My feeling is
On Fri, Jun 1, 2018 at 5:54 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> It is an error to mutate the dictionary *and then continue to iterate over
>> it*.
>
>
> But if you're processing the last key, and you add one so
> that it's no longer the last key, what should happen?
>
> My feeli
Chris Angelico wrote:
It is an error to mutate the dictionary *and then continue to iterate over it*.
But if you're processing the last key, and you add one so
that it's no longer the last key, what should happen?
My feeling is that this should be an error, because it's
not clear whether itera
On Fri, Jun 1, 2018 at 12:37 AM, Frank Millman wrote:
> "Steven D'Aprano" wrote in message news:peorib$1f4$2...@blaine.gmane.org...
>>
>>
>> On Thu, 31 May 2018 10:05:43 +0200, Frank Millman wrote:
>>
>> > From the interpreter session below, you will see that adding a key while
>> > processing th
"Steven D'Aprano" wrote in message news:peorib$1f4$2...@blaine.gmane.org...
On Thu, 31 May 2018 10:05:43 +0200, Frank Millman wrote:
> From the interpreter session below, you will see that adding a key while
> processing the *last* key in an OrderedDict does not give rise to an
> exception.
I
y live program. The message
> from INADA Naoki suggests that it could be inherent in CPython, but I am
> not ready to accept that as an answer yet. I will keep plugging away and
> report back with any findings.
>>
>>
> Ok, I have not found the root cause yet, but I have m
, but I am not
ready to accept that as an answer yet. I will keep plugging away and report
back with any findings.
Ok, I have not found the root cause yet, but I have moved the problem to a
different place, which is progress.
From the interpreter session below, you will see that adding a
ase which remembers for each file what the exact flags to
compile it are (https://clang.llvm.org/docs/JSONCompilationDatabase.html)
To make this *really* work for CFFI you'd have to take all of this into
account -- do you really want to deal with this on the CFFI level?
Eli
>
>
Hi Etienne,
On 5 January 2018 at 10:15, Etienne Robillard wrote:
> Forwarding this thread to the CFFI developers...
>
If you're asking whether we could add libclang as a dependency to CFFI, the
answer is no, sorry.
I feel that I've already explained exactly this to you several times in
private
Forwarding this thread to the CFFI developers...
Re Paul: Thanks for your feedback.
My intended audience are developers who can use hg to fetch/build source
code without pip.
Best regards,
Etienne
Message transféré
Sujet : Re: Progress migrating cffi and
On 4 January 2018 at 21:02, Etienne Robillard wrote:
>> As a fork/extension for cffi, I have no particular opinion (I'm
>> unlikely to ever use it). But the advantage of pycparser is that it's
>> cross-platform and pure Python, so I doubt this will be acceptable for
>> inclusion into CFFI itself.
Hi Paul,
Le 2018-01-04 à 06:41, Paul Moore a écrit :
Presumably that will introduce a dependency on some clang module? You
mention clang.cindex - but the only clang package I can find on PyPI
says "OBSOLETE. LLVM-CLANG NOW PUBLISHES PYTHON PACKAGE.
JUST ADD THE OFFICIAL llvm-3.7 repo in your ap
On 4 January 2018 at 09:50, Etienne Robillard wrote:
> Hi,
>
> I will be creating a repository for this:
> https://bitbucket.org/tkadm30/cffi-libclang
>
> The goal is to generate a AST object from a C header by preprocessing with
> clang -E then compile the python bindings with CFFI...
>
> ffi.cde
Hi,
I will be creating a repository for this:
https://bitbucket.org/tkadm30/cffi-libclang
The goal is to generate a AST object from a C header by preprocessing
with clang -E then compile the python bindings with CFFI...
ffi.cdef(open('uwsgi.h').read()) # <-- XXX need to modify internal
par
Why not make the garbage collector check the reference count before freeing
objects? Only c extensions would increment the ref count while python code
would just use garbage collector making ref count = 0. That way even the
existing c extensions would continue to work.
Regarding to Java using
On 06/22/2017 10:26 PM, Rustom Mody wrote:
Lawrence d'Oliveiro was banned on 30th Sept 2016 till end-of-year
https://mail.python.org/pipermail/python-list/2016-September/714725.html
Is there still a ban?
My apologies to Lawrence, I completely forgot.
The ban is now lifted.
--
~Ethan~
--
htt
Gregory Ewing :
> Lawrence D’Oliveiro wrote:
>> what WOULD you consider to be so “representative”?
>
> I don't claim any of them to be representative. Different GC
> strategies have different characteristics.
My experiences with Hotspot were a bit disheartening. GC is a winning
concept provided t
Lawrence D’Oliveiro wrote:
what WOULD you consider to be so “representative”?
I don't claim any of them to be representative. Different GC
strategies have different characteristics.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Marko Rauhamaa wrote:
And, BTW, my rule of thumb came from experiences with the Hotspot JRE.
I wouldn't take a Java implementation to be representative of
the behaviour of GC systems in general.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On Thursday, June 22, 2017 at 4:28:03 AM UTC+5:30, Steve D'Aprano wrote:
> On Thu, 22 Jun 2017 08:23 am, breamoreboy wrote:
>
> > Don't you know that Lawrence D’Oliveiro has been banned from the mailing
> > list
> > as he hasn't got a clue what he's talking about,
>
> That's not why he was give
On Fri, 23 Jun 2017 01:07 am, breamore...@gmail.com wrote:
> 11 comments on the thread "Instagram: 40% Py3 to 99% Py3 in 10 months" showing
> that he knows as much about Unicode as LDO knows about garabge collection.
Who cares? Every time he opens his mouth to write absolute rubbish he just make
On Jun 22, 2017 4:03 PM, "Chris Angelico" wrote:
On Fri, Jun 23, 2017 at 5:22 AM, CFK wrote:
> On Jun 22, 2017 9:32 AM, "Chris Angelico" wrote:
>
> On Thu, Jun 22, 2017 at 11:24 PM, CFK wrote:
>> When
>> I draw memory usage graphs, I see sawtooth waves to the memory usage
which
>> suggest that
On Fri, Jun 23, 2017 at 5:22 AM, CFK wrote:
> On Jun 22, 2017 9:32 AM, "Chris Angelico" wrote:
>
> On Thu, Jun 22, 2017 at 11:24 PM, CFK wrote:
>> When
>> I draw memory usage graphs, I see sawtooth waves to the memory usage which
>> suggest that the garbage builds up until the GC kicks in and re
On Thursday, June 22, 2017 at 11:07:36 AM UTC-4, bream...@gmail.com wrote:
> On Wednesday, June 21, 2017 at 11:58:03 PM UTC+1, Steve D'Aprano wrote:
> > On Thu, 22 Jun 2017 08:23 am, breamoreboy wrote:
> >
> > > Don't you know that Lawrence D’Oliveiro has been banned from the mailing
> > > list
>
On Jun 22, 2017 9:32 AM, "Chris Angelico" wrote:
On Thu, Jun 22, 2017 at 11:24 PM, CFK wrote:
> When
> I draw memory usage graphs, I see sawtooth waves to the memory usage which
> suggest that the garbage builds up until the GC kicks in and reaps the
> garbage.
Interesting. How do you actually
On Fri, Jun 23, 2017 at 1:48 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> not "aim for 400MB because the garbage collector is only 10%
>> efficient". Get yourself a better garbage collector. Employ Veolia or
>> something.
>
> It's about giving GC room (space- and timewise) to operate. Also, y
Marko Rauhamaa :
> Chris Angelico :
>
>> not "aim for 400MB because the garbage collector is only 10%
>> efficient". Get yourself a better garbage collector. Employ Veolia or
>> something.
>
> It's about giving GC room (space- and timewise) to operate. Also, you
> don't want your memory consumptio
Chris Angelico :
> not "aim for 400MB because the garbage collector is only 10%
> efficient". Get yourself a better garbage collector. Employ Veolia or
> something.
It's about giving GC room (space- and timewise) to operate. Also, you
don't want your memory consumption to hit the RAM ceiling even
On Thu, Jun 22, 2017 at 11:27 PM, Marko Rauhamaa wrote:
> CFK :
>
>> Yes, and this is why I suspect CPython would work well too. My usage
>> pattern may be similar to Python usage patterns. The only way to know for
>> sure is to try it and see what happens.
>
> I have a rule of thumb that your ap
CFK :
> Yes, and this is why I suspect CPython would work well too. My usage
> pattern may be similar to Python usage patterns. The only way to know for
> sure is to try it and see what happens.
I have a rule of thumb that your application should not need more than
10% of the available RAM. If y
On Thu, Jun 22, 2017 at 11:24 PM, CFK wrote:
> When
> I draw memory usage graphs, I see sawtooth waves to the memory usage which
> suggest that the garbage builds up until the GC kicks in and reaps the
> garbage.
Interesting. How do you actually measure this memory usage? Often,
when a GC frees u
On Jun 22, 2017 12:38 AM, "Paul Rubin" wrote:
Lawrence D’Oliveiro writes:
> while “memory footprint” depends on how much memory is actually being
> retained in accessible objects.
If the object won't be re-accessed but is still retained by gc, then
refcounting won't free it either.
> Once agai
On Jun 21, 2017 1:38 AM, "Paul Rubin" wrote:
Cem Karan writes:
> I'm not too sure how much of performance impact that will have. My
> code generates a very large number of tiny, short-lived objects at a
> fairly high rate of speed throughout its lifetime. At least in the
> last iteration of th
Lawrence D’Oliveiro writes:
> while “memory footprint” depends on how much memory is actually being
> retained in accessible objects.
If the object won't be re-accessed but is still retained by gc, then
refcounting won't free it either.
> Once again: The trouble with GC is, it doesn’t know when
On Thu, 22 Jun 2017 10:30 am, Lawrence D’Oliveiro wrote:
> Once again: The trouble with GC is, it doesn’t know when to kick in: it just
> keeps on allocating memory until it runs out.
Once again: no it doesn't.
Are you aware that CPython has a GC? (Or rather, a *second* GC, apart from the
refer
On Thu, 22 Jun 2017 08:23 am, breamore...@gmail.com wrote:
> Don't you know that Lawrence D’Oliveiro has been banned from the mailing list
> as he hasn't got a clue what he's talking about,
That's not why he was given a ban. Being ignorant is not a crime -- if it were,
a lot more of us would be
Lawrence D’Oliveiro writes:
> The trouble with GC is, it doesn’t know when to kick in: it just keeps
> on allocating memory until it runs out.
That's not how GC works, geez. Typically it would run after every N
bytes of memory allocated, for N chosen to balance memory footprint
with cpu overhead
Paul Rubin :
> How it works (i.e. what the implementation does) is quite simple and
> understandable. The amazing thing is that it doesn't leak memory
> catastrophically.
If I understand it correctly, the 32-bit Go language runtime
implementation suffered "catastrophically" at one point. The reas
Cem Karan writes:
> I'm not too sure how much of performance impact that will have. My
> code generates a very large number of tiny, short-lived objects at a
> fairly high rate of speed throughout its lifetime. At least in the
> last iteration of the code, garbage collection consumed less than 1
On Jun 20, 2017, at 1:19 AM, Paul Rubin wrote:
> Cem Karan writes:
>> Can you give examples of how it's not reliable?
>
> Basically there's a chance of it leaking memory by mistaking a data word
> for a pointer. This is unlikely to happen by accident and usually
> inconsequential if it does ha
Paul Rubin :
> The simplest way to start experimenting with GC in Python might be to
> redefine the refcount macros to do nothing, connect the allocator to
> the Boehm GC, and stop all the threads when GC time comes. I don't
> know if Guile has threads at all, but I know it uses the Boehm GC and
>
Cem Karan writes:
> Can you give examples of how it's not reliable?
Basically there's a chance of it leaking memory by mistaking a data word
for a pointer. This is unlikely to happen by accident and usually
inconsequential if it does happen, but maybe there could be malicious
data that makes it
Chris Angelico writes:
> Or let's look at it a different way. Instead of using a PyObject* in C
> code, you could write C++ code that uses a trivial wrapper class that
> holds the pointer, increments its refcount on construction, and
> decrements that refcount on destruction.
That's the C++ STL s
On Tue, Jun 20, 2017 at 1:52 PM, Rustom Mody wrote:
> Saw this this morning
> https://medium.com/@alexdixon/functional-programming-in-javascript-is-an-antipattern-58526819f21e
>
> May seem irrelevant to this, but if JS, FP is replaced by Python, GC it
> becomes
> more on topical
https://rhetting
On Tuesday, June 20, 2017 at 5:53:00 AM UTC+5:30, Cem Karan wrote:
> On Jun 19, 2017, at 6:19 PM, Gregory Ewing wrote:
>
> > Ethan Furman wrote:
> >> Let me ask a different question: How much effort is required at the C
> >> level when using tracing garbage collection?
> >
> > That depends on t
On Jun 19, 2017, at 6:19 PM, Gregory Ewing wrote:
> Ethan Furman wrote:
>> Let me ask a different question: How much effort is required at the C level
>> when using tracing garbage collection?
>
> That depends on the details of the GC implementation, but often
> you end up swapping one form o
Ethan Furman wrote:
Let me ask a different question: How much effort is required at the C
level when using tracing garbage collection?
That depends on the details of the GC implementation, but often
you end up swapping one form of boilerplate (maintaining ref
counts) for another (such as makin
On Tue, Jun 20, 2017 at 1:44 AM, Skip Montanaro
wrote:
> On Mon, Jun 19, 2017 at 10:20 AM, Ethan Furman wrote:
>
>> Programming at the C level is not working in Python, and many Python
>> niceties simply don't exist there.
>
>
> True, but a lot of functionality available to Python programmers exi
On 06/19/2017 08:44 AM, Skip Montanaro wrote:
On Mon, Jun 19, 2017 at 10:20 AM, Ethan Furman wrote:
Programming at the C level is not working in Python, and many Python niceties
simply don't exist there.
True, but a lot of functionality available to Python programmers exists at the
extensi
On Mon, Jun 19, 2017 at 10:20 AM, Ethan Furman wrote:
> Programming at the C level is not working in Python, and many Python
> niceties simply don't exist there.
True, but a lot of functionality available to Python programmers exists at
the extension module level, whether delivered as part of t
On 06/19/2017 08:06 AM, Skip Montanaro wrote:
On Mon, Jun 19, 2017 at 9:20 AM, Ethan Furman wrote:
Reference counting is a valid garbage collecting mechanism, therefore Python is
also a GC language.
Garbage collection is usually thought of as a way to remove responsibility for
tracking of
On Mon, Jun 19, 2017 at 9:20 AM, Ethan Furman wrote:
> Reference counting is a valid garbage collecting mechanism, therefore
> Python is also a GC language.
Garbage collection is usually thought of as a way to remove responsibility
for tracking of live data from the user. Reference counting doe
On Monday, June 19, 2017 at 7:40:49 PM UTC+5:30, Robin Becker wrote:
> On 19/06/2017 01:20, Paul Rubin wrote:
> ...
> > the existing C API quite seriously. Reworking the C modules in the
> > stdlib would be a large but not impossible undertaking. The many
> > external C modules out there woul
On 06/19/2017 07:10 AM, Robin Becker wrote:
I have always found the management of reference counts to be one of the hardest
things about the C api. I'm not sure
exactly how C extensions would/should interact with a GC python. There seem to be
different approaches eg lua & go are
both GC langu
On 19/06/2017 01:20, Paul Rubin wrote:
...
the existing C API quite seriously. Reworking the C modules in the
stdlib would be a large but not impossible undertaking. The many
external C modules out there would be more of an issue.
I have always found the management of reference counts to b
I always thought the GIL removal obstacle was the need to put locks
around every refcount adjustment, and the only real cure for that is to
use a tracing GC. That is a good idea in many ways, but it would break
the existing C API quite seriously. Reworking the C modules in the
stdlib would be a l
On Tue, Jun 13, 2017 at 1:53 PM, Terry Reedy wrote:
> This was tried at least once, perhaps 15 years ago.
Yes, I believe Greg Smith (?) implemented a proof-of-concept in about the
Python 1.4 timeframe. The observation at the time was that it slowed down
single-threaded programs too much to be a
On 6/13/2017 12:09 PM, Robin Becker wrote:
On 11/06/2017 07:27, Steve D'Aprano wrote:
I'm tired of people complaining about the GIL as a "mistake" without
acknowledging that it exists for a reason.
I thought we were also consenting adults about problems arising from bad
extensions. T
On Tue, Jun 13, 2017 at 11:09 AM, Robin Becker wrote:
> I looked at Larry's talk with interest. The GIL is not a requirement as he
> pointed out at the end, both IronPython and Jython don't need it.
But they don't support CPython's extension module API either, I don't
think. (I imagine that mig
On 11/06/2017 07:27, Steve D'Aprano wrote:
I'm tired of people complaining about the GIL as a "mistake" without
acknowledging that it exists for a reason.
I thought we were also consenting adults about problems arising from bad
extensions. The GIL is a blocker for cpython's ability
On Sun, 11 Jun 2017 04:21 pm, Stefan Behnel wrote:
> Serhiy Storchaka schrieb am 11.06.2017 um 07:11:
>> And also GIL is used for guaranteeing atomicity of many operations and
>> consistencity of internal structures without using additional locks. Many
>> parts of the core and the stdlib would j
Serhiy Storchaka schrieb am 11.06.2017 um 07:11:
> 10.06.17 15:54, Steve D'Aprano пише:
>> Larry Hastings is working on removing the GIL from CPython:
>>
>> https://lwn.net/Articles/723949/
>>
>> For those who don't know the background:
>>
>> - The GIL (Global Interpreter Lock) is used to ensure th
10.06.17 15:54, Steve D'Aprano пише:
Larry Hastings is working on removing the GIL from CPython:
https://lwn.net/Articles/723949/
For those who don't know the background:
- The GIL (Global Interpreter Lock) is used to ensure that only one piece of
code can update references to an object at a
On 10-6-2017 14:54, Steve D'Aprano wrote:
> Larry Hastings is working on removing the GIL from CPython:
>
> https://lwn.net/Articles/723949/
Here is Larry's "How's it going" presentation from Pycon 2017 on this subject
https://www.youtube.com/watch?v=pLqv11ScGsQ
-irmen
--
https://mail.python.o
Larry Hastings is working on removing the GIL from CPython:
https://lwn.net/Articles/723949/
For those who don't know the background:
- The GIL (Global Interpreter Lock) is used to ensure that only one piece of
code can update references to an object at a time.
- The downside of the GIL is tha
edification.
>
> At which point your initial code sample will become:
> ###
> p = subprocess.Popen(list(args))
> ###
>
Yeah, 'list is redundant.
Progress is now showing, but I forgot to say that I've lost the
original intent, and that was to
On 11 November 2015 at 17:16, Tim Johnson wrote:
>> (2) [don’t do it] do you need to intercept the lines? If you don’t set
>> stderr= and stdout=, things will print just fine.
> Got to try that before using the module, just for edification.
At which point your initial code sample will become:
#
* Chris Warrick [15 00:55]:
> On 10 November 2015 at 23:47, Tim Johnson wrote:
> > Using python 2.7.6 on ubuntu 14.04
<..>
> There is no \n character at the end — which means that
> p.stdout.readline() cannot return. In fact, if you printed repr() of
> the line you read, you would get this:
gt; youtube-dl as a subprocess.
>
> --
> youtube-dl reports download progress on one line. I.E. the line is
> overwritten numerous times with no carriage return until the
> downloading is finished.
> -
* Tim Johnson [151110 14:55]:
> * Chris Angelico [151110 14:35]:
> > On Wed, Nov 11, 2015 at 9:47 AM, Tim Johnson wrote:
> > > I've written a command-line "wrapper" for youtube-dl, executing
> > is implemented in Python, you might find it easier to "pip install
> > youtube_dl" and work with the
> > > youtube-dl as a subprocess.
> > >
> > > --
> > > youtube-dl reports download progress on one line. I.E. the line is
> > > overwritten numerous times with no carriage return until the
> > > downloading is finished.
> > > --
--
> > youtube-dl reports download progress on one line. I.E. the line is
> > overwritten numerous times with no carriage return until the
> > downloading is finished.
> > --
> >
>
> Sounds to
On Wed, Nov 11, 2015 at 9:47 AM, Tim Johnson wrote:
> I've written a command-line "wrapper" for youtube-dl, executing
> youtube-dl as a subprocess.
>
> --
> youtube-dl reports download progress
eports download progress on one line. I.E. the line is
overwritten numerous times with no carriage return until the
downloading is finished.
--
The following code runs the youtube-dl command and reports each line
as output by youtube-dl
##
On Thu, 28 May 2015 06:03 am, Mark Lawrence wrote:
> You make the statement regarding Python3 "even while it is 10 to 20
> percent slower". Where is your evidence to support this statement?
Its well known that Python 3 is generally slower than Python 2. Cecil's
claim shouldn't be controversial,
On 27/05/2015 16:18, Cecil Westerhof wrote:
Op Wednesday 27 May 2015 16:51 CEST schreef Mark Lawrence:
On 27/05/2015 15:11, Cecil Westerhof wrote:
Op Wednesday 27 May 2015 15:44 CEST schreef Mark Lawrence:
On 27/05/2015 09:42, Cecil Westerhof wrote:
Op Wednesday 27 May 2015 09:30 CEST schre
Op Wednesday 27 May 2015 16:51 CEST schreef Mark Lawrence:
> On 27/05/2015 15:11, Cecil Westerhof wrote:
>> Op Wednesday 27 May 2015 15:44 CEST schreef Mark Lawrence:
>>
>>> On 27/05/2015 09:42, Cecil Westerhof wrote:
Op Wednesday 27 May 2015 09:30 CEST schreef alb:
> But here I have
On 27/05/2015 15:11, Cecil Westerhof wrote:
Op Wednesday 27 May 2015 15:44 CEST schreef Mark Lawrence:
On 27/05/2015 09:42, Cecil Westerhof wrote:
Op Wednesday 27 May 2015 09:30 CEST schreef alb:
But here I have another question, as a python novice is there
really any reason for me to use an
Op Wednesday 27 May 2015 15:44 CEST schreef Mark Lawrence:
> On 27/05/2015 09:42, Cecil Westerhof wrote:
>> Op Wednesday 27 May 2015 09:30 CEST schreef alb:
>>
>>> But here I have another question, as a python novice is there
>>> really any reason for me to use any particular version of Python?
>>
On 27/05/2015 09:42, Cecil Westerhof wrote:
Op Wednesday 27 May 2015 09:30 CEST schreef alb:
But here I have another question, as a python novice is there really
any reason for me to use any particular version of Python?
Should I start directly with the newest? What about 2.7?
In principal y
Op Wednesday 27 May 2015 09:30 CEST schreef alb:
> But here I have another question, as a python novice is there really
> any reason for me to use any particular version of Python?
>
> Should I start directly with the newest? What about 2.7?
In principal you should use the ‘latest’ 3. The only pr
On Wed, May 27, 2015 at 5:30 PM, alb wrote:
> But here I have another question, as a python novice is there really any
> reason for me to use any particular version of Python?
>
> Should I start directly with the newest? What about 2.7?
>
Start with the newest that's conveniently available. With
2015-05-27 9:30 GMT+02:00 alb :
> Hi Mark,
> Mark Lawrence wrote:
> []
>>>File
>>> "/home/debian/repos/2418_IASI-NG/Documents/Tools/tex_tool/venv/local/lib/python3.2/site-packages/progress/bar.py",
>>> line 48
>>> empty_fill = u&#
Hi Mark,
Mark Lawrence wrote:
[]
>>File
>> "/home/debian/repos/2418_IASI-NG/Documents/Tools/tex_tool/venv/local/lib/python3.2/site-packages/progress/bar.py",
>> line 48
>> empty_fill = u'∙'
>>^
>> SyntaxEr
Hi Chris,
Chris Angelico wrote:
[]
>> Python 3.0 removed the 'u' for unicode in front of strings but due to
>> popular demand to ease porting it was reinstated in 3.3. Strip it away and
>> you should be fine to go.
>
> Or upgrade to 3.3 or better; is there anything holding you on 3.2?
> Buildin
1 - 100 of 301 matches
Mail list logo
