Re: for -- else: what was the motivation?

[Dan Stromberg]

The else is executed if you don't "break" out of the loop early.

It cuts down on boolean flags.

On Fri, Oct 7, 2022 at 8:40 PM Axy via Python-list 
wrote:

> Hi there,
>
> this is rather a philosophical question, but I assume I miss something.
> I don't remember I ever used else clause for years I was with python and
> my expectation was it executed only if the the main body was never run.
> Ha-ha! I was caught by this mental trap.
>
> So, seriously, why they needed else if the following pieces produce same
> result? Does anyone know or remember their motivation?
>
> Just curious.
>
> Axy.
>
> print('--- with else')
>
>
> for i in [1,2,3]:
>  print(i)
> else:
>  print(4)
>
> for i in []:
>  print(i)
> else:
>  print(5)
>
> print('--- without else')
>
> for i in [1,2,3]:
>  print(i)
> print(4)
>
> for i in []:
>  print(i)
> print(5)
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

for -- else: what was the motivation?

[Axy via Python-list]

Hi there,

this is rather a philosophical question, but I assume I miss something. 
I don't remember I ever used else clause for years I was with python and 
my expectation was it executed only if the the main body was never run. 
Ha-ha! I was caught by this mental trap.


So, seriously, why they needed else if the following pieces produce same 
result? Does anyone know or remember their motivation?


Just curious.

Axy.

print('--- with else')


for i in [1,2,3]:
    print(i)
else:
    print(4)

for i in []:
    print(i)
else:
    print(5)

print('--- without else')

for i in [1,2,3]:
    print(i)
print(4)

for i in []:
    print(i)
print(5)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Will "hello" always be printed?

[MRAB]

On 2022-10-08 00:40, Cameron Simpson wrote:

On 07Oct2022 20:16, Robin van der veer  wrote:

If I have two processes communicating through a JoinableQueue, and I do the
following:

process 1:

   queue.put(1) #unfished tasks = 1
   queue.join() #block until unfished tasks = 0
   print('hello')[/python]

process 2:

   queue.get()
   queue.task_done() #unfished tasks = 0
   queue.put(1) #unfinished tasks 1[/python]
the unfished tasks refers to what is written in the documentation (
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.JoinableQueue.join
)

will 'hello' always be printed? Or is there a chance that the put in
process 2 executes before process 1 noticed that it should unblock?


I had to read this closely. Yes, the second `put(1)` could execute
before the `join()` commences (or tests), and the `hello` would be
blocked still.


It seems that the whole point of join() is that 'hello' should always be
printed, but I just want to make sure that I understand it correctly.


That's the purpose of using `join`, but you need to use it correctly.
The "some tasks are not completed" condition which `join` supports
doesn't fit what you're doing.

So yes, you're correct in your concern.

Maybe 2 queues would suit you better? Maybe not if they are common.

I would go with 2 queues: 1 for input and 1 for output. The outputted 
item would be either a result or an indication of an error.


[snip]

--
https://mail.python.org/mailman/listinfo/python-list

Re: Will "hello" always be printed?

[Cameron Simpson]

On 07Oct2022 20:16, Robin van der veer  wrote:

If I have two processes communicating through a JoinableQueue, and I do the
following:

process 1:

   queue.put(1) #unfished tasks = 1
   queue.join() #block until unfished tasks = 0
   print('hello')[/python]

process 2:

   queue.get()
   queue.task_done() #unfished tasks = 0
   queue.put(1) #unfinished tasks 1[/python]
the unfished tasks refers to what is written in the documentation (
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.JoinableQueue.join
)

will 'hello' always be printed? Or is there a chance that the put in
process 2 executes before process 1 noticed that it should unblock?


I had to read this closely. Yes, the second `put(1)` could execute 
before the `join()` commences (or tests), and the `hello` would be 
blocked still.



It seems that the whole point of join() is that 'hello' should always be
printed, but I just want to make sure that I understand it correctly.


That's the purpose of using `join`, but you need to use it correctly.  
The "some tasks are not completed" condition which `join` supports 
doesn't fit what you're doing.


So yes, you're correct in your concern.

Maybe 2 queues would suit you better? Maybe not if they are common.

Maybe some kind of blocking counter, so that you could track task 
counts? You'd need to make one, but something which allowed:


count = queue.put(1)
queue.wait_for(count)
print('hello')

and at the other end:

queue.get()
queue.task_done()   # bumps the counter
count2 = queue.put(1)

Here, the counter would not be the internal "unfinished tasks" counter 
but instead a distinct counter which always went up. Probably a pair: 
tasks submitted by `put` and tasks completed by `task_done`. You could 
subclass `JoinableQueue` and add implementations of these counters and 
add a `wait_for(count)` method.


This amounts to assigning each "task" a unique id (the counter) and a 
means to wait for that id.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Debugging automatic quotation in subprocess.Popen()

[Eryk Sun]

On 10/7/22, c.bu...@posteo.jp  wrote:
>
> I need to improve my understanding about how subprocess.Popen() does
> quote arguments. I have special case here.
>
> Simple example:
> Popen(['ls', '-l']) results on a shell in "ls -l" without quotation.

The shell is only used if Popen is instantiated with `shell=True`. The
above example does not use the shell. It runs the "ls" executable
directly. On POSIX systems, fork() and exec() are called to create the
child process. The argument list is passed to exec() and becomes the
argv array of the application's main() entry point function.

On Windows systems, CreateProcessW() is called to created the child
process. It requires a command-line string instead of an argument
array. The argument list gets joined into a command-line string via
subprocess.list2cmdline(), which is based on the rules that are used
by the Windows C runtime library when it parses a command line into
the argv array of an application's [w]main() entry point. That said, a
Windows application is free to parse its command line however it
wants, so listcmdline() is little more than a best guess. On Windows,
Popen() may have to be called directly with a command-line string in
some cases.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Debugging automatic quotation in subprocess.Popen()

[Chris Angelico]

On Sat, 8 Oct 2022 at 08:24,  wrote:
>
> Hello,
>
> I need to improve my understanding about how subprocess.Popen() does
> quote arguments. I have special case here.
>
> Simple example:
> Popen(['ls', '-l']) results on a shell in "ls -l" without quotation.
>
> Quotes are added if they are needed:
> Popen(['ls', 'folder with blank']) results on a shell in
> "ls 'folder with blank'".
>
> Am I right so far with the basics?
>
> Is there a way to be sure and to debug how Popen() give it to the shell?

That's kinda looking at it backwards; the shell first splits the
command into a list of arguments, and then runs it. Python has a
module that is capable of doing similar sorts of work:

https://docs.python.org/3/library/shlex.html

That may be helpful if you want to give the user something to copy and paste.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)

[Julian Smith]

On Fri, 7 Oct 2022 18:28:06 +0100
Barry  wrote:

> > On 7 Oct 2022, at 18:16, MRAB  wrote:
> > 
> > On 2022-10-07 16:45, Skip Montanaro wrote:  
> >>> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames 
> >>> 
> >>> wrote:
> >>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the
> >>> place in calls to `logging.logger.debug()` and friends, evaluating all
> >>> arguments regardless of whether the logger was enabled or not.
> >>>   
> >> I thought there was some discussion about whether and how to efficiently
> >> admit f-strings to the logging package. I'm guessing that's not gone
> >> anywhere (yet).  
> > Letting you pass in a callable to call might help because that you could 
> > use lambda.  
> 
> Yep, that’s the obvious way to avoid expensive log data generation.
> Would need logging module to support that use case.

I have some logging code that uses eval() to evaluate expressions using
locals and globals in a parent stack frame, together with a parser to
find `{...}` items in a string.

I guess this constitutes a (basic) runtime implementation of f-strings.
As such it can avoid expensive evaluation/parsing when disabled, though
it's probably slow when enabled compared to native f-strings. It seems
to work quite well in practise, and also allows one to add some extra
formatting features.

For details see:


https://git.ghostscript.com/?p=mupdf.git;a=blob;f=scripts/jlib.py;h=e85e9f2c4;hb=HEAD#l41

- Jules

-- 
http://op59.net
-- 
https://mail.python.org/mailman/listinfo/python-list

Will "hello" always be printed?

[Robin van der veer]

If I have two processes communicating through a JoinableQueue, and I do the
following:

process 1:

queue.put(1) #unfished tasks = 1
queue.join() #block until unfished tasks = 0
print('hello')[/python]

process 2:

queue.get()
queue.task_done() #unfished tasks = 0
queue.put(1) #unfinished tasks 1[/python]
the unfished tasks refers to what is written in the documentation (
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.JoinableQueue.join
)

will 'hello' always be printed? Or is there a chance that the put in
process 2 executes before process 1 noticed that it should unblock?

It seems that the whole point of join() is that 'hello' should always be
printed, but I just want to make sure that I understand it correctly.
-- 
https://mail.python.org/mailman/listinfo/python-list

Debugging automatic quotation in subprocess.Popen()

[c.buhtz]

Hello,

I need to improve my understanding about how subprocess.Popen() does
quote arguments. I have special case here.

Simple example:
Popen(['ls', '-l']) results on a shell in "ls -l" without quotation.

Quotes are added if they are needed:
Popen(['ls', 'folder with blank']) results on a shell in
"ls 'folder with blank'".

Am I right so far with the basics?

Is there a way to be sure and to debug how Popen() give it to the shell?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Gdal

[Loris Bennett]

Hi Conrado,

"\"Jorge Conrado Conforte\""  writes:

> Hi, 
>
>
>
>
> I installed GDAL using the pip command and conda. But, I did: 
>
> import gdal and I had: 

Depending on your GDAL version, you might find you have to do

  from osgeo import gdal

See

  https://gdal.org/api/python_bindings.html#tutorials

Cheers,

Loris

> Traceback (most recent call last): 
> File "", line 1, in  
> ModuleNotFoundError: No module named 'gdal' 
>
>
>
>
>
> I need gdal to remap some data. 
>
> Please, help me 
>
>
>
>
> Conrado 
-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)

[Barry]

> On 7 Oct 2022, at 19:09, Weatherby,Gerard  wrote:
> The obvious way to avoid log generation is:
> 
> if logger.isEnableFor(logging.DEBUG):
>logger.debug( expensive processing )
> 
> 
> Of course, having logging alter program flow could lead to hard to debug bugs.

Altered flow is less of an issue the the verbosity of the above.
We discussed ways to improve this pattern a few years ago.
That lead to no changes.

What I have used is a class that defines __bool__ to report if logging is 
enabled and __call__ to log. Then you can do this:

log_debug = logger_from(DEBUG)

log_debug and log_debug(‘expensive %s’ % (complex(),))

Barry

> 
> From: Python-list  on 
> behalf of Barry 
> Date: Friday, October 7, 2022 at 1:30 PM
> To: MRAB 
> Cc: python-list@python.org 
> Subject: Re: Ref-strings in logging messages (was: Performance issue with 
> CPython 3.10 + Cython)
> *** Attention: This is an external email. Use caution responding, opening 
> attachments or clicking on links. ***
> 
>> On 7 Oct 2022, at 18:16, MRAB  wrote:
>> 
>> On 2022-10-07 16:45, Skip Montanaro wrote:
 On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames 
 wrote:
 1. The culprit was me. As lazy as I am, I have used f-strings all over the
 place in calls to `logging.logger.debug()` and friends, evaluating all
 arguments regardless of whether the logger was enabled or not.
>>> I thought there was some discussion about whether and how to efficiently
>>> admit f-strings to the logging package. I'm guessing that's not gone
>>> anywhere (yet).
>> Letting you pass in a callable to call might help because that you could use 
>> lambda.
> 
> Yep, that’s the obvious way to avoid expensive log data generation.
> Would need logging module to support that use case.
> 
> Barry
> 
>> --
>> https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$
> 
> --
> https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)

[Weatherby,Gerard]

The obvious way to avoid log generation is:

if logger.isEnableFor(logging.DEBUG):
logger.debug( expensive processing )


Of course, having logging alter program flow could lead to hard to debug bugs.

From: Python-list  on 
behalf of Barry 
Date: Friday, October 7, 2022 at 1:30 PM
To: MRAB 
Cc: python-list@python.org 
Subject: Re: Ref-strings in logging messages (was: Performance issue with 
CPython 3.10 + Cython)
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

> On 7 Oct 2022, at 18:16, MRAB  wrote:
>
> On 2022-10-07 16:45, Skip Montanaro wrote:
>>> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames 
>>> wrote:
>>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the
>>> place in calls to `logging.logger.debug()` and friends, evaluating all
>>> arguments regardless of whether the logger was enabled or not.
>>>
>> I thought there was some discussion about whether and how to efficiently
>> admit f-strings to the logging package. I'm guessing that's not gone
>> anywhere (yet).
> Letting you pass in a callable to call might help because that you could use 
> lambda.

Yep, that’s the obvious way to avoid expensive log data generation.
Would need logging module to support that use case.

Barry

> --
> https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$
>

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)

[Barry]

> On 7 Oct 2022, at 18:16, MRAB  wrote:
> 
> On 2022-10-07 16:45, Skip Montanaro wrote:
>>> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames 
>>> wrote:
>>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the
>>> place in calls to `logging.logger.debug()` and friends, evaluating all
>>> arguments regardless of whether the logger was enabled or not.
>>> 
>> I thought there was some discussion about whether and how to efficiently
>> admit f-strings to the logging package. I'm guessing that's not gone
>> anywhere (yet).
> Letting you pass in a callable to call might help because that you could use 
> lambda.

Yep, that’s the obvious way to avoid expensive log data generation.
Would need logging module to support that use case.

Barry

> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)

[MRAB]

On 2022-10-07 16:45, Skip Montanaro wrote:

On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames 
wrote:


1. The culprit was me. As lazy as I am, I have used f-strings all over the
place in calls to `logging.logger.debug()` and friends, evaluating all
arguments regardless of whether the logger was enabled or not.



I thought there was some discussion about whether and how to efficiently
admit f-strings to the logging package. I'm guessing that's not gone
anywhere (yet).

Letting you pass in a callable to call might help because that you could 
use lambda.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)

[Barry]

> On 7 Oct 2022, at 16:48, Skip Montanaro  wrote:
> 
> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames 
> wrote:
> 
>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the
>> place in calls to `logging.logger.debug()` and friends, evaluating all
>> arguments regardless of whether the logger was enabled or not.
>> 
> 
> I thought there was some discussion about whether and how to efficiently
> admit f-strings to the logging package. I'm guessing that's not gone
> anywhere (yet).

That cannot be done as the f-string is computed before the log call.

Maybe you are thinking of the lazy expression idea for this. That idea
seems to have got no where as its not clear how to implement it without
performance issues.

Barry

> 
> Skip
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)

[Skip Montanaro]

Dang autocorrect. Subject first word was supposed to be "f-strings" not
"ref-strings." Sorry about that.

S

On Fri, Oct 7, 2022, 10:45 AM Skip Montanaro 
wrote:

>
>
> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames 
> wrote:
>
>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the
>> place in calls to `logging.logger.debug()` and friends, evaluating all
>> arguments regardless of whether the logger was enabled or not.
>>
>
> I thought there was some discussion about whether and how to efficiently
> admit f-strings to the logging package. I'm guessing that's not gone
> anywhere (yet).
>
> Skip
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)

[Skip Montanaro]

On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames 
wrote:

> 1. The culprit was me. As lazy as I am, I have used f-strings all over the
> place in calls to `logging.logger.debug()` and friends, evaluating all
> arguments regardless of whether the logger was enabled or not.
>

I thought there was some discussion about whether and how to efficiently
admit f-strings to the logging package. I'm guessing that's not gone
anywhere (yet).

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Performance issue with CPython 3.10 + Cython

[Andreas Ames]

Answering to myself, just for the records:

1. The culprit was me. As lazy as I am, I have used f-strings all over the
place in calls to `logging.logger.debug()` and friends, evaluating all
arguments regardless of whether the logger was enabled or not.  Replacing
these f-strings by regular printf-like format strings solved the issue.
Now the application bowls happily along, consistently below 0.02 seconds
per second application time.
2. Valgrind + callgrind is an awesome toolchain to spot performance issues,
even on VMs.


Am Di., 4. Okt. 2022 um 11:05 Uhr schrieb Andreas Ames <
andreas.0815.qwe...@gmail.com>:

> Hi all,
>
> I am wrapping an embedded application (, which does not use any dynamic
> memory management,) using Cython to call it from CPython.  The wrapped
> application uses a cyclic executive, i.e. everything is done in the
> input-logic-output design, typical for some real-time related domains.
> Consequentially, every application cycle executes more or less the very
> same code.  As I am still in a prototyping stadium, the wrapped process is
> completely CPU-bound, i.e. except of some logging output there is no I/O
> whatsoever.
>
> During one second of "application time", I am doing exactly 120 calls into
> the application through three Cython-wrapped API functions.  The
> application uses some platform-dependent APIs, which I have also wrapped
> with Cython, so that there are numerous callbacks into the Python realm per
> call into the application. What I am observing now, is that the performance
> per "application second" decreases (remember: executing code that does the
> same thing on every cycle) and extending the number of loop iterations does
> not seem to cause any bound to this decrease.  In the log ouput below, you
> can see the GC counts, which look innocent to me.  The "real time" is
> measured using "time.time()". The "top" utility does not suggest any memory
> leak either.  I am developing on WSL2, but I have checked that this
> performance effect also happens on physical machines.  Right now, I am
> staring at "kcachegrind", but I have no idea, how to determine time series
> for the performance of functions (I am not looking for those functions,
> which need the most time, but for those, which consume more and more
> execution time).
>
> One more thing to look for could be memory fragmentation, but before that
> I would like to ask the experts here for their ideas and experiences and/or
> for tools, which could help to find the culprit.
>
> 2022-10-04 10:40:50|INFO|__main__   |Execution loop 0 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.06862711906433105 seconds real time.
>> 2022-10-04 10:40:51|INFO|__main__   |Execution loop 100 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.08224177360534668 seconds real time.
>> 2022-10-04 10:40:52|INFO|__main__   |Execution loop 200 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.08225250244140625 seconds real time.
>> 2022-10-04 10:40:53|INFO|__main__   |Execution loop 300 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.10176873207092285 seconds real time.
>> 2022-10-04 10:40:54|INFO|__main__   |Execution loop 400 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.10900592803955078 seconds real time.
>> 2022-10-04 10:40:55|INFO|__main__   |Execution loop 500 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.12233948707580566 seconds real time.
>> 2022-10-04 10:40:56|INFO|__main__   |Execution loop 600 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.14058256149291992 seconds real time.
>> 2022-10-04 10:40:58|INFO|__main__   |Execution loop 700 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.14777183532714844 seconds real time.
>> 2022-10-04 10:40:59|INFO|__main__   |Execution loop 800 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.15729451179504395 seconds real time.
>> 2022-10-04 10:41:01|INFO|__main__   |Execution loop 900 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.17365813255310059 seconds real time.
>> 2022-10-04 10:41:03|INFO|__main__   |Execution loop 1000 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.17772984504699707 seconds real time.
>> 2022-10-04 10:41:05|INFO|__main__   |Execution loop 1100 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.1955263614654541 seconds real time.
>> 2022-10-04 10:41:07|INFO|__main__   |Execution loop 1200 done. GC
>> counts = (381, 9, 3); 1 second of application time corresponds to
>> 0.20046710968017578 seconds real time.
>> 2022-10-04 10:41:09|INFO|__main__   

Re: Gdal

[Dioumacor FAYE]

If you are working on ubuntu, you can use this command.
conda create --name pygdal
conda activate pygdal
conda install -c conda-forge gdal
If installation completes import it from:
from osgeo import gdal

Le ven. 7 oct. 2022 à 12:01, "Jorge Conrado Conforte" <
jorge.confo...@inpe.br> a écrit :

>
>
> Hi,
>
>
>
>
> I installed GDAL using the pip command and conda. But, I did:
>
> import gdal and I had:
>
> Traceback (most recent call last):
> File "", line 1, in 
> ModuleNotFoundError: No module named 'gdal'
>
>
>
>
>
> I need gdal to remap some data.
>
> Please, help me
>
>
>
>
> Conrado
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Bien à vous,
---  -
  -
Dioumacor FAYE doctorant au  LPAOSF/ESP/UCAD/BP 5085 Dakar-Fann, Sénégal.
Tel labo: (00221) 33 825 93 64
Email: d.faye20171...@zig.univ.snTel:
+221773475098   +221783484308
Physicien en herbe
Pseudo Skype:   dioumacorfaye
-- 
https://mail.python.org/mailman/listinfo/python-list

Gdal

["Jorge Conrado Conforte"]

Hi, 




I installed GDAL using the pip command and conda. But, I did: 

import gdal and I had: 

Traceback (most recent call last): 
File "", line 1, in  
ModuleNotFoundError: No module named 'gdal' 





I need gdal to remap some data. 

Please, help me 




Conrado 
-- 
https://mail.python.org/mailman/listinfo/python-list

How to create forecast lead time with python?

[Dioumacor FAYE]

Hello,
I wanted to create on different days the deadline forecast files (2, 3, 4,
and 5 deadlines). The file is in NetCDF format. The objective is to see
later on these different forecast deadlines which one gives the best score.
If anyone can help me to do?

-- 
Bien à vous,
---  -
  -
Dioumacor FAYE doctorant au  LPAOSF/ESP/UCAD/BP 5085 Dakar-Fann, Sénégal.
Tel labo: (00221) 33 825 93 64
Email: d.faye20171...@zig.univ.snTel:
+221773475098   +221783484308
Physicien en herbe
Pseudo Skype:   dioumacorfaye
-- 
https://mail.python.org/mailman/listinfo/python-list