date:20201010

[issue42005] profile/cProfile CLI should catch BrokenPipeError

2020-10-10 Thread Zhiming Wang



Change by Zhiming Wang :


--
keywords: +patch
pull_requests: +21617
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22643

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39828] json.tool should catch BrokenPipeError

2020-10-10 Thread Zhiming Wang



Change by Zhiming Wang :


--
nosy: +zmwangx
nosy_count: 5.0 -> 6.0
pull_requests: +21618
pull_request: https://github.com/python/cpython/pull/22643

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42005] profile/cProfile CLI should catch BrokenPipeError

2020-10-10 Thread Zhiming Wang



New submission from Zhiming Wang :

Since profile/cProfile CLI interface prints a sorted list of stats, using head 
to limit output to the most relevant entries should be a fairly natural thing 
to do. Unfortunately, BrokenPipeError isn't caught, causing quite a bit of 
pollution to the output:

$ python3 -m cProfile -m http.server -h | head
usage: http.server [-h] [--cgi] [--bind ADDRESS] [--directory DIRECTORY]
   [port]

positional arguments:
  port  Specify alternate port [default: 8000]

optional arguments:
  -h, --helpshow this help message and exit
  --cgi Run as CGI Server
  --bind ADDRESS, -b ADDRESS
Traceback (most recent call last):
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/runpy.py", line 197, 
in _run_module_as_main
return _run_code(code, main_globals, None,
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/runpy.py", line 87, 
in _run_code
exec(code, run_globals)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/cProfile.py", line 
180, in 
main()
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/cProfile.py", line 
173, in main
runctx(code, globs, None, options.outfile, options.sort)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/cProfile.py", line 
19, in runctx
return _pyprofile._Utils(Profile).runctx(statement, globals, locals,
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/profile.py", line 66, 
in runctx
self._show(prof, filename, sort)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/profile.py", line 72, 
in _show
prof.print_stats(sort)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/cProfile.py", line 
42, in print_stats
pstats.Stats(self).strip_dirs().sort_stats(sort).print_stats()
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/pstats.py", line 431, 
in print_stats
self.print_line(func)
  File "/Users/zmwang/.pyenv/versions/3.9.0/lib/python3.9/pstats.py", line 513, 
in print_line
print(f8(tt/nc), end=' ', file=self.stream)
BrokenPipeError: [Errno 32] Broken pipe
Exception ignored in: <_io.TextIOWrapper name='' mode='w' 
encoding='utf-8'>
BrokenPipeError: [Errno 32] Broken pipe

I think the exception should be caught in order to suppress this noise.

--
components: Library (Lib)
messages: 378421
nosy: zmwangx
priority: normal
severity: normal
status: open
title: profile/cProfile CLI should catch BrokenPipeError
type: behavior
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

For Creatives and Developers Only

2020-10-10 Thread Joe Mayami

We are recruiting Developers, and Creatives to join our community into building 
personal portfolios, personal development skills, work on Open Source Projects, 
Devops, Collaboration, User Testing and Supports.

Community members include experts in product designs, python programming, data 
science, creative writers, graphics and designs, artificial intelligence and a 
lot more.

Link to join: https://chat.whatsapp.com/Geld8FNt4QCLGhYpA8DxkG
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python's carbon guilt

2020-10-10 Thread Terry Reedy

On 10/10/2020 11:58 AM, Peter Pearson wrote:

Python advocates might want to organize their thoughts on
this subject before their bosses spring the suggestion:

From
https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change
:

. . . Astronomers should also abandon popular programming languages
such as Python in favor of efficient compiled languages. Languages
such as Fortran and C++, Zwart calculates, are more than 100 times
more carbon efficient than Python because they require fewer
operations.

Here is my reply to the "senior correspondent for astronomy..." who
wrote the columm.

---

Dear Mr. Clery:

You report that Zwart of Leiden U says ...

"Astronomers should also abandon popular programming languages such as
Python in favor of efficient compiled languages. Languages such as
Fortran and C++, Zwart calculates, are more than 100 times more carbon
efficient than Python because they require fewer operations."

Summary counter claim: the claim is phony. As actually used by
astronomers for computationally intensive tasks, Python is nearly if not
as 'carbon efficient' -- because nearly all the computation is done with
machine code compiled from C, Fortran, C++, or whatever.

(I am not an expert here, but am reporting to you a summary of what is
generally known among experienced Python users. I am leaving out
numerous details. Feel free to contact scientific Python experts for more.)

Here is how anti-Python, pro-OtherLanguage people come up with such
misleading numbers as '100x slower'. Confuse the issue by ascribing
efficiency to languages rather than implementations. Then compare a
relatively efficient 'production' implementation of some algorithm in
OtherLanguage to an computer inefficient (but human efficient)
'development' implementation in Python that ignores how Python is being
used in practice by scientific communities, such as the astronomy community.

Step 1: Create a file with couple of numerically intensive functions
such as matrix_init and matrix_invert written in directly compiled
OtherLanguage. Add calls to matrix_init and matrix_invert. Time one or
more runs.

Step 2: Naively translate OtherLanguage directly into Python. Don't
allow imports. Time one or more runs with the CPython interpreter.
Compare the OtherLanguage time to this worst case Python time. Imply
that users of Python are stupid enough to stop here for production
usage. I consider this a bit slanderous.

In practice, Python users inverting matrices, for instance, import the
compiled numpy module, which among other things, wraps the standard
Linpack package, which uses machine-specific, assemble-coded, Basic
Linear Algebra Subroutines (BLAS) when available. In practice, I have
read, the overhead of calling C libraries from Python instead of C is
only a few percent.

The original and still main Python implementation, CPython, is written
in C. It interprets Python code, which is 'slow', but the Python code
can include calls to fast, compiled, pre-written C functions. CPython
was designed from the beginning to be extended with other other modules
and functions written in C. (Fortran extensions were included either
immediately or soon after, but I don't know which.) Some of these are
included in the standard library, others from third-parties.

Since the release of Python 1.0 in 1992, real-world Python users, have
been extending CPython when appropriate for production usage. Indeed,
numerical scientific computation was Python's first 'killer
application'. Now, most every open-source C library with significant
usage has been wrapped. There are at least hundreds. The current
standard numerical package, numpy, is the third, and the needs of
astronomers were among those that contributed to the design.

--
Terry Jan Reedy

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

[issue42001] Deprecate `typing.io` Wrapper Namespace

2020-10-10 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Truncation error

2020-10-10 Thread Grant Edwards

On 2020-10-10, Peter J. Holzer  wrote:
> On 2020-10-07 07:53:55 +0200, Marco Sulla wrote:
>> If you want to avoid float problems, you can use Decimal:
>
> Decimal doesn't avoid floating point problems, because it is a floating
> point format. For example:
> [...]

> >>> from decimal import *
> >>> a = Decimal(3)
> >>> a
> Decimal('3')
> >>> b = Decimal(1E50)
> >>> b
> Decimal('17629769841091887003294964970946560')
> [...]

There are two problems with your code:

 1. You meant Decimal('1e50').  What you typed creates a Decimal value
from the IEEE 64-bit floating point value closest to 1e50.

 2. You need to increase the context precision.  It defaults to 28,
and you're example needs it to be at least 51:

>>> getcontext().prec = 100
>>> a = Decimal(3)
>>> b = Decimal('1e50')
>>> c = Decimal(2)
>>> a + b - c - b
Decimal('1')
>>> b - b + a - c
Decimal('1')
>>> a + (b - b) - c
Decimal('1')
>>> a + b - b - c
Decimal('1')

Like other floating point systems, you still need to know what you're
doing if you want to get the "right" results.

--
Grant

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

Re: Python's carbon guilt

2020-10-10 Thread Tim Daneliuk

On 10/10/20 2:35 PM, Marco Sulla wrote:
> He should also calculate the carbon dioxide emitted by brains that
> works in C++ only. I omit other sources.
> 


yes, methane is an alleged greenhouse gas as well
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trying to Download PygameZero

2020-10-10 Thread Terry Reedy


On 10/10/2020 11:11 AM, Mats Wichmann wrote:

On 10/10/20 12:22 AM, Tom Hedge via Python-list wrote:
I am in a 8 grade coding class at the moment and my teacher asked me to download a script 

... [on Windows according to file paths]... .


The problem is the pygame developers have not released a pygame for
Python 3.9 and you're using Python 3.9.


https://www.lfd.uci.edu/~gohlke/pythonlibs/ has wheels for pygame. 
('wheel' is the distribution format use by pypi.)  Download to you 
system and install with pip from that.


--
Terry Jan Reedy

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

[issue41972] bytes.find consistently hangs in a particular scenario

2020-10-10 Thread Tim Peters



Tim Peters  added the comment:

Ya, the case for the diff is at best marginal. Note that while it may be 
theoretically provable that the extra test would make the worst cases slower, 
that's almost certainly not measurable. The extra test would almost never be 
executed in the worst cases: in those the last characters of the needle and 
haystack DO match, and we spend almost all the total time in the

for (j = 0; j < mlast; j++)

loop.  The extra test is only in the branch where the last characters _don't_ 
match.

In that branch, it's already certain that the last haystack character does not 
match the last needle character, so in a probabilistic sense, for "random" data 
that increases the odds that the last haystack character isn't in the needle at 
all. In which case the payoff is relatively large compared to the cost of the 
test (can skip len(needle) positions at once, instead of only 1).

I don't believe this can be out-thought. It would require timing on "typical" 
real-life searches. Which are likely impossible to obtain ;-)

Offhand do you know what the _best_ timing for two-way search is in a 
pattern-not-found case? The algorithm is too complicated for that to be 
apparent to me at a glance. As Fredrik said in the post of his I linked to, he 
was very keen to have an algorithm with best case sublinear time. For example, 
the one we have takes best-case not-found O(n/m) time (where n is the haystack 
length and m the needle length).  For example, searching for 'B' * 1_000_000 in 
'A' * 10_000_000 fails after just 9 character comparisons (well, not counting 
the million less 1 compares to initialize `skip` to the ultimately useless 0).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42003] After changing to list or tuple, will the original parameter change?

2020-10-10 Thread Steven D'Aprano



Steven D'Aprano  added the comment:

This is not a bug. In Python 2, zip() returns a list, so you can use it over 
and over again. But in Python 3, zip() returns an iterator, and you can only 
use iterators once. After you have used the iterator, it is exhausted and there 
is nothing left.

So the behaviour you see is expected and intentional.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Problem saving datetime to file and reading it back for a calculation

2020-10-10 Thread Chris Angelico

On Sun, Oct 11, 2020 at 12:57 PM Cameron Simpson  wrote:
> Personally I strongly dislike using datetimes for computation or as the
> basis for time record keeping, essentially because of the timezone issue
> but also because the human calendar is a complex disaster of illfitting
> units (days in a year? variable; days in a month? variable; that table
> of days per unit? variable depending on your time in history).
>
> Instead, I always try to work in POSIX timestamps, an absolute number of
> seconds since midnight, 1 January 1970 GMT. You can always do arithmetic
> directly between these in seconds, then convert for presentation
> purposes whenever.
>

Absolutely agree, with the annoying exception of recurring events. If
a human says "this happens every Monday at 2pm", then the human
expects it to recur every Monday at 2pm, not every 604800 seconds. The
difference shows up when the conversion between UTC and local time
changes - most commonly when Daylight Saving Time starts or ends...

(And I guess if you care about leap seconds, then Unix time would be
inappropriate there too. But I rather doubt that most of us are
bothered by that.)

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

Re: Problem saving datetime to file and reading it back for a calculation

2020-10-10 Thread Cameron Simpson

On 10Oct2020 18:17, Steve  wrote:
>I would like to use the line:
>HoursDiff = int((d2-d1).total_seconds()/3600)
>to determine the difference in hours between two timedate entries.
>
>The variable d2 is from datetime.now()
>and d1 is read from a text file.
>
>I can save d2 to the file only if I convert it to string and, at a later
>date, it gets read back in as d1 as string.

That is the nature of text files.

>The variable d1 as string will
>not work in the HoursDiff statement.

Because it is a string.

Peter has described a way to transcribe a datetime in an arbitrary string 
format and back. Note that his example formats are "naive" - they don't know 
what you timezone is, and you want that if that ever varies (not just 
datetimes in contexts from different places, but also at different times of 
the year if you run different summer and winter times, particularly 
troublesome around the transition from one to the other).

>To me, it looks like a problem in formatting.
>How do I fix this?

Personally I strongly dislike using datetimes for computation or as the 
basis for time record keeping, essentially because of the timezone issue 
but also because the human calendar is a complex disaster of illfitting 
units (days in a year? variable; days in a month? variable; that table 
of days per unit? variable depending on your time in history).

Instead, I always try to work in POSIX timestamps, an absolute number of 
seconds since midnight, 1 January 1970 GMT. You can always do arithmetic 
directly between these in seconds, then convert for presentation 
purposes whenever.

Because you're now working in seconds directly, you go:

HoursDiff = int((t2-t1)/3600)

or:

HoursDiff = (t2-t1) // 3600

When you first collect your datetime, convert it to a POSIX timestamp 
immediately. If you're _starting_ from datetime.now(), do not do that! Just 
start with time.time() and no conversion is needed at all.

Just _present_ in datetime formats if you need to. DO NOT try to work 
with them as your basic type - they are a source of pitfalls.

As far as storing timestamps in a file, they're ints or floats; just 
write them out.

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

[issue42004] Allow uploading files with SimpleHTTPRequestHandler

2020-10-10 Thread Javier Ayres



New submission from Javier Ayres :

Hello. I'm a big fan of the http.server module to quickly serve some files in a 
local network with `python3 -m http.server`. I regularly needed to get some 
files from other people too, but getting everyone to install/run python3 was 
not such a simple task. Eventually I wrote a subclass of 
SimpleHTTPRequestHandler that added a form with a file input and accepted POST 
requests, so people could also upload files to my computer. I think this would 
be a fine addition to SimpleHTTPRequestHandler, so I'm attaching a potential 
patch that implements this and adds a new cli parameter so this feature is only 
enabled explicitly.

--
components: Library (Lib)
files: patch
messages: 378418
nosy: lufte
priority: normal
severity: normal
status: open
title: Allow uploading files with SimpleHTTPRequestHandler
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49506/patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Problem saving datetime to file and reading it back for a calculation

2020-10-10 Thread Peter Pearson

On Sat, 10 Oct 2020 18:17:26 -0400, Steve  wrote:
> I would like to use the line:
> HoursDiff = int((d2-d1).total_seconds()/3600)
> to determine the difference in hours between two timedate entries.
>
> The variable d2 is from datetime.now()
> and d1 is read from a text file.
>
> I can save d2 to the file only if I convert it to string and, at a later
> date, it gets read back in as d1 as string.   The variable d1 as string will
> not work in the HoursDiff statement.
>
> To me, it looks like a problem in formatting.
> How do I fix this?

datetime.datetime.strftime and datetime.datetime.strptime ?

>>> t = datetime.datetime.now()
>>> t.strftime("%Y-%m-%d %H:%M:%S")
'2020-10-10 18:02:33'
>>> b = datetime.datetime.strptime("2020-09-09 12:34:56", "%Y-%m-%d %H:%M:%S")
>>> b.strftime("%Y-%m-%d %H:%M:%S")
'2020-09-09 12:34:56'
>>> 

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

aiosnow

2020-10-10 Thread Robert Wikman

Happy to announce a project I've been working on for some time that's
finally in beta: aiosnow, a MIT licensed Python 3 client library for
interacting with an ITSM cloud service, providing something not too
dissimilar to a database ORM.

I'm sharing this here as the library makes use of Python asyncio, and other
cool features like:
- Asynchronous generators, context managers
- Query condition chaining using Python bitwise operators
- Model Schema system implemented using Marshmallow
- The aiohttp library for working with remote HTTP APIs

It was built with modularity in mind, and is meant to be forked, hacked and
consumed in other projects - commercial or otherwise.

What's in it for me?
I do this for fun, to learn, and to support the asyncio backend of another
project I'm working on, which uses this library at its core.

GitHub page:
https://github.com/rbw/aiosnow

Technical documentation:
https://aiosnow.readthedocs.io/en/latest

Big thanks to the code contributors and donors!

--
Robert Wikman
0xf6feb506ae5d3762
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

Guppy 3/Heapy 3.1.0

2020-10-10 Thread YiFei Zhu

I am happy to announce Guppy 3 3.1.0

Guppy 3 is a library and programming environment for Python,
currently providing in particular the Heapy subsystem, which supports
object and heap memory sizing, profiling and debugging. It also
includes a prototypical specification language, the Guppy
Specification Language (GSL), which can be used to formally specify
aspects of Python programs and generate tests and documentation from a
common source.

Guppy 3 is a fork of Guppy-PE, created by Sverker Nilsson for Python 2.

This is a major feature release. The main news in this release:

o Python 3.9 support, without subinterpreter support or inter-interpreter
  traversal.
o Added .byprod classifier via tracemalloc, and .prod to print tracemalloc
  traceback.
o Added .all to print all lines in a MorePrinter buffer.
o Added R_INSET relation for being contained by an unordered set.

License: MIT

The project homepage is on GitHub:

https://github.com/zhuyifei1999/guppy3

Enjoy,

YiFei Zhu
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[issue42003] After changing to list or tuple, will the original parameter change?

2020-10-10 Thread foxpython_2020



New submission from foxpython_2020 :

c = dict(zip(['one', 'two', 'three'], [1, 2, 3]))
print("1:",c) # right: {'one': 1, 'two': 2, 'three': 3}

b= zip(['one', 'two', 'three'], [1, 2, 3])
a= list(b) #Because of this line of code, the result is different
print("2:",dict(b)) #wrong: {}

b= zip(['one', 'two', 'three'], [1, 2, 3])
a= tuple(b) #Because of this line of code, the result is different
print("2:",dict(b)) #wrong: {}

--
messages: 378417
nosy: foxpython_2020
priority: normal
severity: normal
status: open
title: After changing to list or tuple, will the original parameter change?

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Problem saving datetime to file and reading it back for a calculation

2020-10-10 Thread Steve

I would like to use the line:
HoursDiff = int((d2-d1).total_seconds()/3600)
to determine the difference in hours between two timedate entries.

The variable d2 is from datetime.now()
and d1 is read from a text file.

I can save d2 to the file only if I convert it to string and, at a later
date, it gets read back in as d1 as string.   The variable d1 as string will
not work in the HoursDiff statement.

To me, it looks like a problem in formatting.
How do I fix this?

Steve


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

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default in Python 3.10

2020-10-10 Thread Guido van Rossum



Guido van Rossum  added the comment:


New changeset 0ae216b11644b23511c6287a52e7d28aeb9f by Batuhan Taskaya in 
branch 'master':
bpo-38605: bump the magic number for 'annotations' future (#22630)
https://github.com/python/cpython/commit/0ae216b11644b23511c6287a52e7d28aeb9f


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

RE: Python's carbon guilt

2020-10-10 Thread Avi Gross via Python-list

People have a tendency to go too far in their religious zeal, Peter.

We could go back to writing on chalkboards to do calculations then re-use
the chalk dust when erasing to write again.

Many computers do almost nothing 90+ percent of the time. Want to outlaw
those or force them to accept random jobs from the internet when relatively
idle?

But all kidding aside, anything used frequently and not changed often might
be a good candidate for an efficient solution that uses fewer resources. Yet
our computers, so far, have been in many ways getting cheaper and in many
cases use less electricity to do the same number of calculations. But there
are tradeoffs such as optimizing speed over memory use or other resources
that are external and thus slower. 

The ultimate carbon cost can sometimes be for  carbon-based organisms, most
of them suitable to be called human. When you measure how long it takes them
to develop applications and verify they have minimal bugs, you may notice
that some development environments seem to take lots more time than others
for common tasks. Interactive has huge advantages in many cases. Slowest
would be asking people to go back to writing in machine code, not very
portably.

The reality is that speed and other resource use do matter for anything run
often or that would take a very long time. Languages like python and R
acknowledge that and quite a few parts are now replaced by calls to
libraries in other language or C/C++ code. But often that is done only later
when the code is not going to be changed regularly.

I think there is a reality here. The costs of computing end sometimes of
power usage, often are dropping. The users like getting extra features and
underneath the covers, that often means lots of extra IF statements or other
checks, or loops that keep checking regularly to see if they need to do
anything.  If you program a GUI that allows the user to click or type in
many places at random, there can be lots of overhead even when done in a
compiled language. True speed and efficiency might require removing lots of
features entirely as too expensive. It may well be cheaper to do some
operations on matrices where every row/column is of the same object type but
there are very serious advantages to allowing a mixed type operation such as
a data.frame where each column is a hidden vector of some type or even at
times to allowing every cell/item to be of any object type. The overhead
rises in terms of storage and CPU time used but it allows higher levels of
abstraction and often the ability to write code with fewer lines that
handles many more conditions, sometimes invisibly. 

Consider how computing is being used and ask if a little more carbon
footprint there may reduce the carbon footprint elsewhere. Would you rather
have people spend years or months developing some app that can be used in a
way that reduces overall carbon dioxide production?

If your answer is that you can have it both ways, fine. But you may have
trouble hiring enough people willing to work under those constraints and you
may be told of lots of things they won't feel comfortable doing and it may
take longer and ...

A question. Are recent compiled languages that add features as small and
fast as earlier ones? For example, many older languages required a function
to take a fixed number of arguments in a fixed order and of exactly the
types mentioned when created. Some interpreted languages allow lots of
additional functionality, some of which could easily be provided such as
allowing named arguments in any order, or allowing additional optional
arguments or default values and so on. Much of this could be done in a
compiled way, but with additional compile time and even run-time cost. But
some features, by definition, must be at run time and especially for code
that modifies itself or creates new objects dynamically. IF you want some of
these new features, how would you supply them in a compiled way without
adding lots of the overhead you want to reduce? 

Carbon guilt should not be taken seriously as an immediate goal as compared
to an overall goal. If we make more people able to work from home or nearby
offices and avoid long commutes, does it matter if your remote work is much
more carbon friendly than the costs to travel and then still use other
energy there for lighting and more computers and ...




-Original Message-
From: Python-list  On
Behalf Of Peter Pearson
Sent: Saturday, October 10, 2020 11:58 AM
To: python-list@python.org
Subject: Python's carbon guilt

Python advocates might want to organize their thoughts on this subject
before their bosses spring the suggestion:

From
https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confr
ont-their-role-and-vulnerability-climate-change :

. . . Astronomers should also abandon popular programming languages
such as Python in favor of efficient compiled languages. Languages
such as Fortran and C++, Zwart calculates, are

1 2 >

1 - 100 of 102 matches

Mail list logo