Re: src layout for projects seems not so popular

[Abdur-Rahmaan Janhangeer]

Also a takeaway from my package experience is that even though __init__.py
is
not needed for module import, it's still needed for packaging (py3.8). Find
won't
find the module else.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[MRAB]

On 2021-08-31 02:16, dn via Python-list wrote:

On 31/08/2021 11.07, Dennis Lee Bieber wrote:

On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
 declaimed the following:

...


Might have helped to mention you were in China... To me, CST is North
America Central Standard Time (and I'd have expected this time of year to
see CDT - Central Daylight Time)... That led me on a weird meaningless side
track...

...


I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.



Which is correct?

CST in China
https://www.timeanddate.com/time/zones/cst-china

CST in North America
https://www.timeanddate.com/time/zones/cst

and not to mention Cuba
https://www.timeanddate.com/time/zones/


[snip]
What annoys me is when someone starts that a webinar will start at, say, 
xx ET. I have to know which country that person is in and whether 
daylight savings is currently in effect (EST or EDT?) so that I can 
convert to my local time.


It's so much easier to use UTC.

I know what timezone I'm in and whether daylight savings is currently in 
effect here, so I know the local offset from UTC.

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Tue, Aug 31, 2021 at 8:55 PM MRAB  wrote:
>
> On 2021-08-31 02:16, dn via Python-list wrote:
> > On 31/08/2021 11.07, Dennis Lee Bieber wrote:
> >> On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
> >>  declaimed the following:
> > ...
> >
> >>  Might have helped to mention you were in China... To me, CST is North
> >> America Central Standard Time (and I'd have expected this time of year to
> >> see CDT - Central Daylight Time)... That led me on a weird meaningless side
> >> track...
> > ...
> >
> >>  I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.
> >
> >
> > Which is correct?
> >
> > CST in China
> > https://www.timeanddate.com/time/zones/cst-china
> >
> > CST in North America
> > https://www.timeanddate.com/time/zones/cst
> >
> > and not to mention Cuba
> > https://www.timeanddate.com/time/zones/
> >
> [snip]
> What annoys me is when someone starts that a webinar will start at, say,
> xx ET. I have to know which country that person is in and whether
> daylight savings is currently in effect (EST or EDT?) so that I can
> convert to my local time.

If someone says "ET", then I would assume they mean America/New_York -
it seems that only in the US do people so utterly assume that everyone
else is in the same country. In Europe, I hear people say "CEST" and
such (though I still prefer "Europe/Prague" or whatever country
they're in), so the only issue there is that they don't always say
"CEDT" when it's daylight time.

> It's so much easier to use UTC.
>
> I know what timezone I'm in and whether daylight savings is currently in
> effect here, so I know the local offset from UTC.

Yeah. I do recommend making good use of the IANA tzinfo database
though (especially since Python 3.9 made that a bit easier to access),
as it's usually easier to get people to tell you what city/state
they're in, rather than whether daylight time will be active or not.
(It might take a little bit of translation to figure out that, for
instance, New Brunswick CA is America/Halifax, but that's not too hard
usually.) Letting tzinfo do all the work means you don't have to fret
about anyone's daylight saving transition dates, or whether they've
decided to change their clocks by half an hour to be different from
Japan's clocks, or to have DST not applicable during Ramadan, or to
have double DST, or double-negative DST. And yes, those are all real,
because you can't make up anything as insane as actual clock politics.

(I find the Ireland situation particularly amusing. Northern Ireland,
being part of the UK, operates on London time, with clocks advancing
one hour for summer. The Republic of Ireland, on the other hand, has a
standard time which is one hour later than Greenwich's, but then they
subtract an hour during winter, returning to standard time in summer.
So when the rest of Europe adds an hour, Ireland stops subtracting
one. Clocks in Belfast and Dublin always show the same times.)

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

Re: PEP Idea: Real private attribute

[Calvin Spealman]

The right way for those decorators to hold some private information, imho,
isn't to put anything on the decorated object at all, but to use a weak-ref
dictionary using the target object as a key.

On Sat, Aug 28, 2021 at 5:42 PM Mehrzad Saremi 
wrote:

> Python currently uses name mangling for double-underscore attributes. Name
> mangling is not an ideal method to avoid name conflicting. There are
> various normal programming patterns that can simply cause name conflicting
> in double-underscore members. A typical example is when a class is
> re-decorated using the same decorator. The decorator can not take
> double-underscore members without name conflicts. For example:
>
> ```
> @custom_decorator("a")
> @custom_decorator("b")
> class C:
> pass
> ```
>
> The `@custom_decorator` wrapper may need to hold private members, but
> Python's current name conflict resolution does not provide any solution and
> the decorator cannot hold private members without applying tricky
> programming methods.
>
> Another example is when a class inherits from a base class of the same
> name.
>
> ```
> class View:
> """A class representing a view of an object; similar to
> numpy.ndarray.view"""
> pass
>
> class Object:
> class View(View):
> """A view class costumized for objects of type Object"""
> pass
> ```
>
> Again, in this example, class `Object.View` can't take double-underscore
> names without conflicting with `View`'s.
>
> My idea is to introduce real private members (by which I do not mean to be
> inaccessible from outside the class, but to be guaranteed not to conflict
> with other private members of the same object). These private members are
> started with triple underscores and are stored in a separate dictionary
> named `__privs__`. Unlike `__dict__` that takes 'str' keys, `__privs__`
> will be a double layer dictionary that takes 'type' keys in the first
> level, and 'str' keys in the second level.
>
> For example, assume that the user runs the following code:
> ```
> class C:
> def __init__(self, value):
> self.___member = value
>
> c = C("my value")
> ```
>
> On the last line, Python's attribute setter creates a new entry in the
> dictionary with key `C`, adds the value "my value" to a new entry with the
> key 'member'.
>
> The user can then retrieve `c.___member` by invoking the `__privs__`
> dictionary:
>
> ```
> print(c.__privs__[C]['member'])  # prints 'my value'
> ```
>
> Note that, unlike class names, class objects are unique and there will not
> be any conflicts. Python classes are hashable and can be dictionary keys.
> Personally, I do not see any disadvantage of using __privs__ over name
> mangling/double-underscores. While name mangling does not truly guarantee
> conflict resolution, __privs__ does.
>
> Please discuss the idea, let me know what you think about it, whether there
> are possible disadvantages, and if you think it will be approved as a PEP.
>
> Thanks,
> Mehrzad Saremi
>
> AI M.Sc. grad. from AUT
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Making command-line args available to deeply-nested functions

[George Fischhof]

George Fischhof  ezt írta (időpont: 2021. aug. 29., V,
21:27):

>
>
> Loris Bennett  ezt írta (időpont: 2021. aug.
> 26., Cs, 16:02):
>
>> George Fischhof  writes:
>>
>> [snip (79 lines)]
>>
>> >> > Hi,
>> >> >
>> >> > Also you can give a try to click and / or  typer packages.
>> >> > Putting args into environment variables can be a solution too
>> >> > All of these depends on several things: personal preferences,
>> colleagues
>> >> /
>> >> > firm standards, the program, readability, variable accessibility (IDE
>> >> > support, auto completition) (env vars not supported by IDEs as they
>> are
>> >> not
>> >> > part of code)
>> >>
>> >> Thanks for the pointers, although I have only just got my head around
>> >> argparse/configargparse, so click is something I might have a look at
>> >> for future project.
>> >>
>> >> However, the question of how to parse the arguments is somewhat
>> separate
>> >> from that of how to pass (or not pass) the arguments around within a
>> >> program.
>>
>> [snip (16 lines)]
>> >
>> > Hi,
>> > I thought not just parsing, but the usage method: you add a decorator to
>> > the function where you want to use the parameters. This way you do not
>> have
>> > to pass the value through the calling hierarchy.
>> >
>> > Note: typer is a newer package, it contains click and leverages command
>> > line parsing even more.
>>
>> Do you have an example of how this is done?  From a cursory reading of
>> the documentation, it didn't seem obvious to me how to do this, but then
>> I don't have much understanding of how decorators work.
>>
>> Cheers,
>>
>> Loris
>>
>>
>> --
>> This signature is currently under construction.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>
>
> Hi,
>
> will create a sample code on Monday - Tuesday
>
> BR,
> George
>


Hi,

here is the program ;-) (see below)
typer does not uses decorators, to solve this problem they advice to use
click's decorators, mixing typer and click.
Practically I prefer not to mix them, also the parts for easiest way to do
this just available in latest click, which is not supported in typer.

So I created all the stuff in click, 8.x should be used

BR,
George


import click


# read command line parameters
@click.command()
@click.option('--level_1', help='Level 1')
@click.option('--level_2', help='Level 2')
def main(level_1, level_2):
# put command line parameters into global context
ctx = click.get_current_context()
ctx.meta['level_1'] = level_1
ctx.meta['level_2'] = level_2

level_1_function()


# pass / inject level_1 parameter to this function
@click.decorators.pass_meta_key('level_1')
def level_1_function(level_1):
print(f'level 1 variable: {level_1}')
level_2_function()


# pass / inject level_2 parameter to this function
@click.decorators.pass_meta_key('level_2')
def level_2_function(level_2):
print(f'level 2 variable: {level_2}')


if __name__ == "__main__":
main()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[hongy...@gmail.com]

On Tuesday, August 31, 2021 at 7:55:51 AM UTC+8, Dennis Lee Bieber wrote:
> On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com" 
>  declaimed the following:
> >On Ubuntu 20.04.2 LTS, I use the 
> >[recent2](https://github.com/dotslash/recent2/blob/master/recent2.py) to log 
> >and query my bash history, which uses a sqlite3 database to store the 
> >history information. The `datetime` of running a command is inserted in the 
> >sqlite3 database with [a `unixepoch` 
> >format](https://github.com/dotslash/recent2/blob/f1018aee228c710cc7d1b8b93bc0228791a54563/recent2.py#L45),
> > and it will be converted into `localtime` accordingly when retrieved and 
> >displayed later. 
> >
> As I read it, it is interpreting whatever value was provided as 
> UNIXEPOCH when storing the value -- but stores it as an ISO date/time 
> string! https://www.sqlite.org/lang_datefunc.html 
> 
> sqlite> select datetime(1092941466, 'unixepoch'); 
> 2004-08-19 18:51:06 
> sqlite> 
> sqlite> select datetime('now'); 
> 2021-08-30 22:28:58 
> sqlite> 
> 
> I can't see anything in that code listing that explicitly manipulates 
> the date/time when fetched for output. Nor do I see the connection 
> specifying Python adapter usage: 
> https://docs.python.org/3/library/sqlite3.html#default-adapters-and-converters
>  
> so I'd expect the output to be in ISO UTC format; the native result of 
> using SQLite3's datetime().. 
> 
> """ 
> if not args.hide_time: 
> cmd_time = row_dict["command_dt"] 

Thank you very much. Based on your above comments and the discussion on 
,
 I fixed this problem by the following method:

# Install and import some necessary packages: 
from datetime import datetime
# pip install python-dateutil
from dateutil import tz

 
Then use the following codes to do the trick:

from_zone = tz.tzutc()
to_zone = tz.tzlocal()
cmd_time = row_dict["command_dt"]
cmd_time = datetime.strptime(cmd_time, '%Y-%m-%d 
%H:%M:%S').replace(tzinfo=from_zone).astimezone(to_zone).strftime("%Y-%m-%d 
%H:%M:%S")


Best, Hongyi

> if args.time_first: 
> print(f'{Term.YELLOW}{cmd_time}{Term.ENDC} 
> {colored_cmd}') 
> else: 
> padded_cmd = pad(raw_text=row_dict['command'], 
> print_text=colored_cmd) 
> print(f'{padded_cmd} # rtime@ 
> {Term.YELLOW}{cmd_time}{Term.ENDC}')
> """ 
> >But I found that it did not perform the correct conversion according to the 
> >time zone setting on the machine, as shown below: 
> >```shell 
> >werner@X10DAi-00:~$ rm 22 
> >rm: cannot remove '22': No such file or directory 
> >werner@X10DAi-00:~$ recent -fo -w . 2 
> >rm 22 # rtime@ 2021-08-29 10:57:13 
> >werner@X10DAi-00:~$ date 
> >Sun 29 Aug 2021 06:57:22 PM CST 
> >```
> Might have helped to mention you were in China... To me, CST is North 
> America Central Standard Time (and I'd have expected this time of year to 
> see CDT - Central Daylight Time)... That led me on a weird meaningless side 
> track... 
> 
> What documentation do you have that says it will display the date/time 
> in local timezone? (The README appears to be incorrect -- the utility logs 
> unix epoch [UTC seconds since 1970] AS ISO UTC string). 
> 
> sqlite> select datetime(1092941466, 'unixepoch'); 
> 2004-08-19 18:51:06 
> sqlite> select datetime(1092941466, 'unixepoch', 'localtime'); 
> 2004-08-19 14:51:06 
> sqlite> 
> sqlite> select datetime('now', 'localtime'); 
> 2021-08-30 18:50:19 
> sqlite> select datetime('now'); 
> 2021-08-30 22:50:32 
> sqlite> 
> 
> I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC. 
> 
> 
> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: urgent

[jak]

Il 31/08/2021 03:05, Python ha scritto:

Hari wrote:
i was download ur python software but it is like boring user interface 
for

me like young student to learn ,can u have any updates?


God, let me die please...





Oh no, please don't speak in that way ... evidently now that python has
reached its tenth version its prompt is a little boring. It may need to
be replaced. You could open a competition notice to vote on the new
prompt. I would vote for:

:^P>

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

Struggling to understand timedelta rpesentation when applying an offset for an hour earlier - why is days = -1?

[dcs3spp via Python-list]

Hi,

I wonder if anyone can help

I am struggling to understand the representation of timedelta when used in 
conjunction with astimezone. 

Given the code below, in a python interactive interpreter, I am trying to 
calculate a resultant datetime an hour earlier from a UTC datetime

```bash
>>> dt = datetime(2021, 8, 22, 23, 59, 31, tzinfo=timezone.utc)
>>> hour_before=dt.astimezone(timezone(-timedelta(seconds=3600)))
>>> hour_before
datetime.datetime(2021, 8, 22, 22, 59, 31, 
tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=82800)))
```

I cannot understand why the resultant datetime.timedelta is days=-1, 
seconds=82800 (23 hours) .

Why is it not an hour earlier as seconds=-3600? Why is days = -1 when the 
resultant calculated date is the same, year, day, month??
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Alan Gauld via Python-list]

On 31/08/2021 13:45, Chris Angelico wrote:

> (I find the Ireland situation particularly amusing. 

Time zones and daylight saving arrangements in particular are a
nightmare at the micro level. I once worked on a large customer
support application which required all dates/times to be viewable
in UTC plus any of:
- The local support centre's time (eg. Tokyo, Japan)
- The customer organization's local time(eg. Seoul, Korea)
- The local site time (some remote island in the pacific...)

The big problem was the last one since some small countries
have local arrangements for timezones that don't conform to
the official ones. One pacific island had dual "patrons" and to
avoid offending either they adopted a non-standard "timezone"
half-way between the two patron's zones!

In another case we had the principality of Andorra deciding
to put off switching to DST for an extra week because it
would make the snow melt faster and spoil the skiing!
This was decided by the council on the Friday before it
was due to happen and announced on the local radio...

I got more grey hairs on that project than any other.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


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

Create a real-time interactive TUI using Python.

[hongy...@gmail.com]

I want to know whether python can be used to create real-time interactive TUI, 
as hstr [1] does.

[1] https://github.com/dvorka/hstr

Regards,
HY
-- 
https://mail.python.org/mailman/listinfo/python-list

Trouble propagating logging configuration

[Loris Bennett]

Hi,

I am having difficulty getting the my logging configuration passed on
to imported modules.

My initial structure was as follows:

  $ tree blorp/
  blorp/
  |-- blorp
  |   |-- __init__.py
  |   |-- bar.py
  |   |-- foo.py
  |   `-- main.py
  `-- pyproject.toml

whereby the logging configuration is done in main.py.

After thinking about it, I decided maybe the inheritance wasn't working
because main.py is in the same directory as the other files.  So I
changed the structure to

  $ tree blorp/
  blorp/
  |-- blorp
  |   |-- __init__.py
  |   |-- bar.py
  |   `-- foo.py
  |-- main.py
  `-- pyproject.toml

but the logging configuration still is not propagated.

Can anyone at least confirm that moving main.py to the directory above
the other files is the correct thing to do and thus the problem is being
caused by something else?

Cheers,

Loris

-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trouble propagating logging configuration

[Loris Bennett]

"Loris Bennett"  writes:

> Hi,
>
> I am having difficulty getting the my logging configuration passed on
> to imported modules.
>
> My initial structure was as follows:
>
>   $ tree blorp/
>   blorp/
>   |-- blorp
>   |   |-- __init__.py
>   |   |-- bar.py
>   |   |-- foo.py
>   |   `-- main.py
>   `-- pyproject.toml
>
> whereby the logging configuration is done in main.py.
>
> After thinking about it, I decided maybe the inheritance wasn't working
> because main.py is in the same directory as the other files.  So I
> changed the structure to
>
>   $ tree blorp/
>   blorp/
>   |-- blorp
>   |   |-- __init__.py
>   |   |-- bar.py
>   |   `-- foo.py
>   |-- main.py
>   `-- pyproject.toml
>
> but the logging configuration still is not propagated.
>
> Can anyone at least confirm that moving main.py to the directory above
> the other files is the correct thing to do and thus the problem is being
> caused by something else?

I should mention that I am using poetry and thus the program is called
via an entry in the pyproject.toml file such as 

  [tool.poetry.scripts]
  blorp_out = "main:blorp_out"

I have a suspicion that this way of calling the program somehow
interferes with the inheritance mechanism used by logging.

Cheers,

Loris

-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: urgent

[Hari]

Yes, I can. Why do you want python?
option: ?
What task do you want to solve with python?
option: ?
Why python?
option: ?
Why not any other language?
option: ?


On Tue, Aug 31, 2021 at 3:08 AM Igor Korot  wrote:

> Hi,
>
> On Mon, Aug 30, 2021 at 4:34 PM Hari 
> wrote:
> >
> > i was download ur python software but it is like boring user interface
> for
> > me like young student to learn ,can u have any updates?
>
> Can you elaborate a little:
> Why do you want python?
> What task do you want to solve with python?
> Why python? Why not any other language?
>
> Thank you.
>
> > --
> > https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: urgent

[Igor Korot]

Hi,

On Tue, Aug 31, 2021 at 12:44 AM Hari  wrote:
>
> Yes, I can. Why do you want python?
> option: ?

What do you mean - "option".
I am actually asking you why you want python?

> What task do you want to solve with python?
> option: ?

See above.

> Why python?
> option: ?
> Why not any other language?
> option: ?

Those 2 depend on the task at hand.

Thank you.

>
>
> On Tue, Aug 31, 2021 at 3:08 AM Igor Korot  wrote:
>>
>> Hi,
>>
>> On Mon, Aug 30, 2021 at 4:34 PM Hari  wrote:
>> >
>> > i was download ur python software but it is like boring user interface for
>> > me like young student to learn ,can u have any updates?
>>
>> Can you elaborate a little:
>> Why do you want python?
>> What task do you want to solve with python?
>> Why python? Why not any other language?
>>
>> Thank you.
>>
>> > --
>> > https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Create a real-time interactive TUI using Python.

[Chris Angelico]

On Wed, Sep 1, 2021 at 1:59 AM hongy...@gmail.com  wrote:
>
> I want to know whether python can be used to create real-time interactive 
> TUI, as hstr [1] does.
>
> [1] https://github.com/dvorka/hstr
>

Yes.

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

Re: PEP Idea: Real private attribute

[Mehrzad Saremi]

Calvin, even if the language offered truly private members?

On Tue, 31 Aug 2021 at 17:31, Calvin Spealman  wrote:

> The right way for those decorators to hold some private information, imho,
> isn't to put anything on the decorated object at all, but to use a weak-ref
> dictionary using the target object as a key.
>
> On Sat, Aug 28, 2021 at 5:42 PM Mehrzad Saremi 
> wrote:
>
>> Python currently uses name mangling for double-underscore attributes. Name
>> mangling is not an ideal method to avoid name conflicting. There are
>> various normal programming patterns that can simply cause name conflicting
>> in double-underscore members. A typical example is when a class is
>> re-decorated using the same decorator. The decorator can not take
>> double-underscore members without name conflicts. For example:
>>
>> ```
>> @custom_decorator("a")
>> @custom_decorator("b")
>> class C:
>> pass
>> ```
>>
>> The `@custom_decorator` wrapper may need to hold private members, but
>> Python's current name conflict resolution does not provide any solution
>> and
>> the decorator cannot hold private members without applying tricky
>> programming methods.
>>
>> Another example is when a class inherits from a base class of the same
>> name.
>>
>> ```
>> class View:
>> """A class representing a view of an object; similar to
>> numpy.ndarray.view"""
>> pass
>>
>> class Object:
>> class View(View):
>> """A view class costumized for objects of type Object"""
>> pass
>> ```
>>
>> Again, in this example, class `Object.View` can't take double-underscore
>> names without conflicting with `View`'s.
>>
>> My idea is to introduce real private members (by which I do not mean to be
>> inaccessible from outside the class, but to be guaranteed not to conflict
>> with other private members of the same object). These private members are
>> started with triple underscores and are stored in a separate dictionary
>> named `__privs__`. Unlike `__dict__` that takes 'str' keys, `__privs__`
>> will be a double layer dictionary that takes 'type' keys in the first
>> level, and 'str' keys in the second level.
>>
>> For example, assume that the user runs the following code:
>> ```
>> class C:
>> def __init__(self, value):
>> self.___member = value
>>
>> c = C("my value")
>> ```
>>
>> On the last line, Python's attribute setter creates a new entry in the
>> dictionary with key `C`, adds the value "my value" to a new entry with the
>> key 'member'.
>>
>> The user can then retrieve `c.___member` by invoking the `__privs__`
>> dictionary:
>>
>> ```
>> print(c.__privs__[C]['member'])  # prints 'my value'
>> ```
>>
>> Note that, unlike class names, class objects are unique and there will not
>> be any conflicts. Python classes are hashable and can be dictionary keys.
>> Personally, I do not see any disadvantage of using __privs__ over name
>> mangling/double-underscores. While name mangling does not truly guarantee
>> conflict resolution, __privs__ does.
>>
>> Please discuss the idea, let me know what you think about it, whether
>> there
>> are possible disadvantages, and if you think it will be approved as a PEP.
>>
>> Thanks,
>> Mehrzad Saremi
>>
>> AI M.Sc. grad. from AUT
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>>
>
> --
>
> CALVIN SPEALMAN
>
> SENIOR QUALITY ENGINEER
>
> calvin.speal...@redhat.com  M: +1.336.210.5107
> [image: https://red.ht/sig] 
> TRIED. TESTED. TRUSTED. 
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trouble propagating logging configuration

[Dieter Maurer]

Loris Bennett wrote at 2021-8-31 15:25 +0200:
>I am having difficulty getting the my logging configuration passed on
>to imported modules.
>
>My initial structure was as follows:
>
>  $ tree blorp/
>  blorp/
>  |-- blorp
>  |   |-- __init__.py
>  |   |-- bar.py
>  |   |-- foo.py
>  |   `-- main.py
>  `-- pyproject.toml
>
>whereby the logging configuration is done in main.py.
>
>After thinking about it, I decided maybe the inheritance wasn't working
>because main.py is in the same directory as the other files.

Should you speak about Python's `logging` module, then
the "inheritance" does not depend on the source layout.
Instead, it is based on the hierarchy of dotted names.
It is completely up to you which dotted names you are using
in your `getLogger` calls.

Furthermore, the place of the configuration (and where in the
code it is activated) is completely irrelevant for the "inheritance".

For details, read the Python documentation for the `logging` module.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: src layout for projects seems not so popular

[Paul Bryan]

An interesting thread in PyPA (with links to other threads) discussing
src layout:
https://github.com/pypa/packaging.python.org/issues/320

On Tue, 2021-08-31 at 10:53 +0400, Abdur-Rahmaan Janhangeer wrote:
> Greetings list,
> 
> Just an observation. Out of Github's trending repos for
> Python for today, I could find only 2 repos using the src layout.
> Matplotlib and another one.
> https://github.com/trending/python?since=daily
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> about  | blog
> 
> github 
> Mauritius

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

Re: Struggling to understand timedelta rpesentation when applying an offset for an hour earlier - why is days = -1?

[Chris Angelico]

On Wed, Sep 1, 2021 at 1:55 AM dcs3spp via Python-list
 wrote:
>
> Hi,
>
> I wonder if anyone can help
>
> I am struggling to understand the representation of timedelta when used in 
> conjunction with astimezone.
>
> Given the code below, in a python interactive interpreter, I am trying to 
> calculate a resultant datetime an hour earlier from a UTC datetime
>
> ```bash
> >>> dt = datetime(2021, 8, 22, 23, 59, 31, tzinfo=timezone.utc)
> >>> hour_before=dt.astimezone(timezone(-timedelta(seconds=3600)))
> >>> hour_before
> datetime.datetime(2021, 8, 22, 22, 59, 31, 
> tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=82800)))
> ```
>
> I cannot understand why the resultant datetime.timedelta is days=-1, 
> seconds=82800 (23 hours) .
>
> Why is it not an hour earlier as seconds=-3600? Why is days = -1 when the 
> resultant calculated date is the same, year, day, month??

It's consistent with modulo arithmetic:

>>> x = -3600
>>> x // 86400
-1
>>> x % 86400
82800

>>> help(datetime.timedelta)
...
 |  --
 |  Data descriptors defined here:
 |
 |  days
 |  Number of days.
 |
 |  microseconds
 |  Number of microseconds (>= 0 and less than 1 second).
 |
 |  seconds
 |  Number of seconds (>= 0 and less than 1 day).
 |
 |  --

The sub-day portions are guaranteed to be zero or above, meaning that
a small negative offset is described as "a day ago, plus 23 hours"
rather than "an hour ago". It's the exact same thing, though.

If you would prefer to see ALL components negative, just negate the
timedelta and then negate each component; that will give you an
equivalent timedelta.

>>> datetime.timedelta(seconds=-3600)
datetime.timedelta(days=-1, seconds=82800)
>>> -datetime.timedelta(seconds=-3600)
datetime.timedelta(seconds=3600)
>>> datetime.timedelta(seconds=-3600-86400)
datetime.timedelta(days=-2, seconds=82800)
>>> -datetime.timedelta(seconds=-3600-86400)
datetime.timedelta(days=1, seconds=3600)

Hope that explains it!

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[dn via Python-list]

On 01/09/2021 00.45, Chris Angelico wrote:
> On Tue, Aug 31, 2021 at 8:55 PM MRAB  wrote:
>> On 2021-08-31 02:16, dn via Python-list wrote:
>>> On 31/08/2021 11.07, Dennis Lee Bieber wrote:
 On Sun, 29 Aug 2021 19:49:19 -0700 (PDT), "hongy...@gmail.com"
  declaimed the following:
>>> ...
>>>
  Might have helped to mention you were in China... To me, CST is North
 America Central Standard Time (and I'd have expected this time of year to
 see CDT - Central Daylight Time)... That led me on a weird meaningless side
 track...
>>> ...
>>>
  I'm in EDT (Eastern Daylight Time) -- so 4 hours behind UTC.
>>>
>>>
>> What annoys me is when someone starts that a webinar will start at, say,
>> xx ET. I have to know which country that person is in and whether
>> daylight savings is currently in effect (EST or EDT?) so that I can
>> convert to my local time.
> 
> If someone says "ET", then I would assume they mean America/New_York -
> it seems that only in the US do people so utterly assume that everyone
> else is in the same country. In Europe, I hear people say "CEST" and
> such (though I still prefer "Europe/Prague" or whatever country
> they're in), so the only issue there is that they don't always say
> "CEDT" when it's daylight time.

We tackle the inter-related subjects of "localisation" and
"internationalisation" in our (non-Python) training courses.

The 'problem' with a local-time, eg "0900 ET" (as above), is that it is
local. It is really only intended to communicate locally.

The definitions of "local" and 'local understanding' do vary. For
example, Australia stretches over multiple time-zones and thus people in
Melbourne are familiar with the idea of adjusting a Sydney-time to their
local clock. Similarly, US-based folk. However, many other localities
don't have such concerns and thus don't think that way!


At the level of "inter-personal communication", should one say (only)
what is in your head, or perform the 'translation' as a politeness to
your reader?

In @Chris' example, 'the reader' could be anywhere in the world. So, it
would be difficult, and lengthy, to provide for all - but should you
write such an invitation 'for all' ("Hi Everyone"), or should it be
addressed to the individual reader ("Dear Colleague")?

After years (decades!) of being woken in the early-hours of the morning
by (time-zone-ignorant) colleagues, my recommendation is to use both!


If the invitation is mine, typically I will write ("transmit") my local
time, because that is how I'm thinking as I type. On a
second-pass/editing the text, I will be considering how the reader will
"receive" the information.

If we're talking about a staff-meeting, it may be possible to list the
reader's time/date. In the case of an webinar hoping to attract
international participation, the recommendation is to add a
UTC-equivalent. (ideas developed, below)



>> It's so much easier to use UTC.
>>
>> I know what timezone I'm in and whether daylight savings is currently in
>> effect here, so I know the local offset from UTC.

Exactly! The very purpose of having an "international" standard.

Also, the very reason why Python has two groups of time-and-date
functions - so that one may work in local-time, or international-time/UTC.


Please note, the adjustments described (offsets) are *numeric*.
Accordingly, being told that one of our members resides 'at' UTC-4, and
knowing that I am currently at UTC+12, we can figure-out a 16-hour
'time-difference'.

NB in reality, having too few fingers, I would go 'the other way' (ie 24
- 16 ) and work with the idea that our colleague's clock is eight-hours
'ahead' of mine (so, as I've recently 'passed' 0800, that would make it
~1600/4pm for him - remembering that I am already 'in' Wednesday,
whereas Americans are still struggling to catch-up by finishing Tuesday)


> Yeah. I do recommend making good use of the IANA tzinfo database
> though (especially since Python 3.9 made that a bit easier to access),
> as it's usually easier to get people to tell you what city/state
> they're in, rather than whether daylight time will be active or not.
> (It might take a little bit of translation to figure out that, for
> instance, New Brunswick CA is America/Halifax, but that's not too hard
> usually.) Letting tzinfo do all the work means you don't have to fret
> about anyone's daylight saving transition dates, or whether they've
> decided to change their clocks by half an hour to be different from
> Japan's clocks, or to have DST not applicable during Ramadan, or to
> have double DST, or double-negative DST. And yes, those are all real,
> because you can't make up anything as insane as actual clock politics.

So, given that it is a NUMERIC calculation, dispense with "New Brunswick
CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
time numerically: "17:00-3"

Given that, someone at UTC-4 knows that his/her 

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 6:38 AM dn via Python-list
 wrote:
> > Yeah. I do recommend making good use of the IANA tzinfo database
> > though (especially since Python 3.9 made that a bit easier to access),
> > as it's usually easier to get people to tell you what city/state
> > they're in, rather than whether daylight time will be active or not.
> > (It might take a little bit of translation to figure out that, for
> > instance, New Brunswick CA is America/Halifax, but that's not too hard
> > usually.) Letting tzinfo do all the work means you don't have to fret
> > about anyone's daylight saving transition dates, or whether they've
> > decided to change their clocks by half an hour to be different from
> > Japan's clocks, or to have DST not applicable during Ramadan, or to
> > have double DST, or double-negative DST. And yes, those are all real,
> > because you can't make up anything as insane as actual clock politics.
>
> So, given that it is a NUMERIC calculation, dispense with "New Brunswick
> CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
> Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
> time numerically: "17:00-3"
>
> Given that, someone at UTC-4 knows that his/her rendez-vous will be
> "1600", and I can figure it to be "0800" for me:
>
> 1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
> and
> 1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
>   rounding to 24hrs: 08:00
>   (the next day)

No, that's not reliable... because of that abomination called Daylight
Saving Time. Since I used New Brunswick, and since she's just gone
online, I'll use a specific example:

DeviCat livestreams at 6pm every Tuesday (and other times, but I'm
going to focus on a weekly event here). Since she lives in NB, Canada,
she defines that time by what IANA refers to as America/Halifax.

I want to be there at the start of each stream, since I'm one of her
moderators. But I live in a suburb of Melbourne - my clock shows what
IANA calls Australia/Melbourne.

To turn this into a purely mathematical calculation, you have to know
exactly when she will go on or off DST, and when I will go on or off.
Trying to turn it into an offset is going to fail badly as soon as you
talk about "next Tuesday" and one of us is shifting DST this weekend.

That's why it's better to let Python (or something) handle the whole
thing. Don't concern yourself with exactly what the hour differences
are, or which way DST is going, or anything; just convert Halifax time
to Melbourne time.

> For many of us, the mental-calculations are relatively easy to manage.
> For Python the code is trivial. Computation is easier than terminology
> 'translation' (particularly when one has to research the terms first!
> - did you know what "ADT" meant?)

I asked DeviCat what country and province ("state" in other regions)
she lived in, and then confirmed with her that Halifax time was what
her clock showed. The term "ADT" was never relevant.

In a lot of situations, you don't even need to ask the human - you can
let the web browser or desktop app report the timezone. The app can
say something like "In order to schedule this event,  will need to
know your time zone. Is that okay?" and then send the IANA timezone
name.

> Teasing @Chris: I'm not sure why it should be amusing that two entities
> called 'Ireland' should have different time-zones (pot?kettle) - after
> all, does "Western Australia" use the same time-zone as "South
> Australia"? For that matter, the same as the bulk of the Australian
> population?

Western Australia uses Australia/Perth timezone, and South Australia
uses Australia/Adelaide. They're different base times from the east
coast where I am by two hours, and half an hour, respectively; and
they have different DST rules.

On the east coast, we all have the same winter time, but in summer,
Melbourne, Sydney, and Hobart move clocks forward, but Brisbane
doesn't.

> The time-zone which perplexes me most, is India. This because it is not
> only a different hour, but also requires a 30-minute off-set - operating
> at UTC+5:30!

Yup, we got that too... Adelaide is half an hour back from Melbourne
(UTC+9:30). But it gets worse. Kathmandu is on a quarter hour. And the
Chatham Islands (part of New Zealand) are 12:45 ahead of UTC in
winter, and then they add an hour of DST in summer, putting them at
UTC+13:45.

> Fortunately, like China, the entire country (officially) operates in the
> same time-zone. Accordingly, there is less consideration about
> working-out what time it is in Pune cf Kolkata, than between (say) San
> Francisco and Denver - although they are in the same country, are they
> in the same time-zone, or not?
> (they aren't!)

That would be convenient for working within China, but on the flip
side, it means that geographically-nearby locations can have vastly
different clocks. Oh, and 

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[2QdxY4RzWzUUiLuE]

On 2021-09-01 at 08:36:55 +1200,
dn via Python-list  wrote:

> ... there is less consideration about working-out what time it is in
> Pune cf Kolkata, than between (say) San Francisco and Denver -
> although they are in the same country, are they in the same time-zone,
> or not?  (they aren't!)

What about Phoenix?  In the winter, it's the same time there as it is in
San Francisco, but in the summer, it's the same time there as it is in
Denver (Phoenix doesn't observe Daylight Saving Time).

And then there's Indiana, a medium size state that tends to get ignored
(they used to advertise "there's more than just corn in Indiana").  Most
of Indiana is in US/Eastern, but the cities that are (for practical
purposes) suburbs of Chicago are in US/Central (aka America/Chicago).

ChrisA is right; you can't make this [stuff] up.

Having lived in the United States my entire life (and being a nerd), I
can confirm that (1) I'm used to it and handle it as well as possible,
but (2) many people are not and don't.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 7:17 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-09-01 at 08:36:55 +1200,
> dn via Python-list  wrote:
>
> > ... there is less consideration about working-out what time it is in
> > Pune cf Kolkata, than between (say) San Francisco and Denver -
> > although they are in the same country, are they in the same time-zone,
> > or not?  (they aren't!)
>
> What about Phoenix?  In the winter, it's the same time there as it is in
> San Francisco, but in the summer, it's the same time there as it is in
> Denver (Phoenix doesn't observe Daylight Saving Time).

I prefer to say: In winter, San Francisco (or Los Angeles) is the same
as Phoenix, but in summer, Los Angeles changes its clocks away, and
Denver changes to happen to be the same as Phoenix.

> And then there's Indiana, a medium size state that tends to get ignored
> (they used to advertise "there's more than just corn in Indiana").  Most
> of Indiana is in US/Eastern, but the cities that are (for practical
> purposes) suburbs of Chicago are in US/Central (aka America/Chicago).

At least the US has governed DST transitions. As I understand it, any
given city has to follow one of the standard time zones, and may
EITHER have no summer time, OR transition at precisely 2AM/3AM local
time on the federally-specified dates. (I think the EU has also
mandated something similar for member states.)

If we could abolish DST world-wide, life would be far easier. All the
rest of it would be easy enough to handle.

> ChrisA is right; you can't make this [stuff] up.

Yeah. And if you think you've heard it all, sign up for the
tzdata-announce mailing list and wait for the next phenomenon. I think
Egypt (Africa/Cairo) is currently in the lead for weirdest timezone
change, for (with short notice) announcing that they'd have DST during
summer but not during Ramadan. Since "summer" is defined by a solar
calendar and "Ramadan" is defined by a lunar calendar, that means the
DST exclusion might happen entirely in winter (no effect), at one end
or other of summer (shortens DST, just changes the dates), or in the
middle of summer (DST on, DST off, DST on, DST off, in a single year).
But they will, at some point, be eclipsed by an even more bizarre
timezone change. I don't dare try to predict what will happen, because
I know that the reality will be even worse

> Having lived in the United States my entire life (and being a nerd), I
> can confirm that (1) I'm used to it and handle it as well as possible,
> but (2) many people are not and don't.

Yup, absolutely. I've been working internationally for a number of
years now, so my employment has been defined by a clock that isn't my
own. I got used to it and developed tools and habits, but far too many
people don't, and assume that simple "add X hours" conversions
suffice.

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[2QdxY4RzWzUUiLuE]

On 2021-09-01 at 07:32:43 +1000,
Chris Angelico  wrote:

> On Wed, Sep 1, 2021 at 7:17 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:

> > What about Phoenix?  In the winter, it's the same time there as it is in
> > San Francisco, but in the summer, it's the same time there as it is in
> > Denver (Phoenix doesn't observe Daylight Saving Time).
> 
> I prefer to say: In winter, San Francisco (or Los Angeles) is the same
> as Phoenix, but in summer, Los Angeles changes its clocks away, and
> Denver changes to happen to be the same as Phoenix.

Not exactly.  Sort of.  Phoenix and Denver are both in America/Denver
(aka US/Mountain), but only Denver observes DST.  San Francisco and Los
Angeles are both in America/Los_Angeles, and both observe DST.

> At least the US has governed DST transitions. As I understand it, any
> given city has to follow one of the standard time zones, and may
> EITHER have no summer time, OR transition at precisely 2AM/3AM local
> time on the federally-specified dates. (I think the EU has also
> mandated something similar for member states.)

That's my understanding, too.

> If we could abolish DST world-wide, life would be far easier. All the
> rest of it would be easy enough to handle.

Agreed.

> ... I think Egypt (Africa/Cairo) is currently in the lead for weirdest
> timezone change ...

Yeah, I read about that somewhere.  Remember when the Pope declared that
September should skip a bunch of days?

> > Having lived in the United States my entire life (and being a nerd), I
> > can confirm that (1) I'm used to it and handle it as well as possible,
> > but (2) many people are not and don't.
> 
> Yup, absolutely. I've been working internationally for a number of
> years now, so my employment has been defined by a clock that isn't my
> own. I got used to it and developed tools and habits, but far too many
> people don't, and assume that simple "add X hours" conversions
> suffice.

Way back in the 1990s, I was working with teams in Metro Chicago, Tel
Aviv, and Tokyo (three separate teams, three really separate time zones,
at least two seaprate DST transition dates).  I changed my wristwatch to
24 hour time (and never looked back).  I tried UTC for a while, which
was cute, but confusing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 7:54 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-09-01 at 07:32:43 +1000,
> Chris Angelico  wrote:
>
> > On Wed, Sep 1, 2021 at 7:17 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> > > What about Phoenix?  In the winter, it's the same time there as it is in
> > > San Francisco, but in the summer, it's the same time there as it is in
> > > Denver (Phoenix doesn't observe Daylight Saving Time).
> >
> > I prefer to say: In winter, San Francisco (or Los Angeles) is the same
> > as Phoenix, but in summer, Los Angeles changes its clocks away, and
> > Denver changes to happen to be the same as Phoenix.
>
> Not exactly.  Sort of.  Phoenix and Denver are both in America/Denver
> (aka US/Mountain), but only Denver observes DST.  San Francisco and Los
> Angeles are both in America/Los_Angeles, and both observe DST.

America/Phoenix is a separate time zone from America/Denver. During
winter they represent the same time, but during summer, Phoenix
doesn't change its offset, and Denver does.

(San Francisco isn't an IANA timezone; the city precisely follows Los
Angeles time.)

> > ... I think Egypt (Africa/Cairo) is currently in the lead for weirdest
> > timezone change ...
>
> Yeah, I read about that somewhere.  Remember when the Pope declared that
> September should skip a bunch of days?

Well, that's from transitioning from the Julian calendar to the
Gregorian. The same transition was done in different countries at
different times. The Pope made the declaration for the Catholic church
in 1582, and all countries whose official religion was Catholic
changed at the same time; other countries chose their own schedules
for the transition. Notably, Russia converted in 1918, immediately
after the "October Revolution", which happened on the 25th of October
on the Julian calendar, but the 7th of November on the Gregorian.

> Way back in the 1990s, I was working with teams in Metro Chicago, Tel
> Aviv, and Tokyo (three separate teams, three really separate time zones,
> at least two seaprate DST transition dates).  I changed my wristwatch to
> 24 hour time (and never looked back).  I tried UTC for a while, which
> was cute, but confusing.

I tried UTC for a while too, but it became easier to revert to local
time for my watch and just do the conversions directly.

Perhaps, in the future, we will all standardize on UTC, and daylight
time will be a historical relic. And then, perhaps, we will start
getting frustrated at relativity-based time discrepancies ("it's such
a pain scheduling anything with someone on Mars, their clocks move
faster than ours do!").

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[MRAB]

On 2021-08-31 22:53, 2qdxy4rzwzuui...@potatochowder.com wrote:

On 2021-09-01 at 07:32:43 +1000,
Chris Angelico  wrote:


On Wed, Sep 1, 2021 at 7:17 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:



> What about Phoenix?  In the winter, it's the same time there as it is in
> San Francisco, but in the summer, it's the same time there as it is in
> Denver (Phoenix doesn't observe Daylight Saving Time).

I prefer to say: In winter, San Francisco (or Los Angeles) is the same
as Phoenix, but in summer, Los Angeles changes its clocks away, and
Denver changes to happen to be the same as Phoenix.


Not exactly.  Sort of.  Phoenix and Denver are both in America/Denver
(aka US/Mountain), but only Denver observes DST.  San Francisco and Los
Angeles are both in America/Los_Angeles, and both observe DST.


At least the US has governed DST transitions. As I understand it, any
given city has to follow one of the standard time zones, and may
EITHER have no summer time, OR transition at precisely 2AM/3AM local
time on the federally-specified dates. (I think the EU has also
mandated something similar for member states.)


That's my understanding, too.


[snip]
In the EU, DST in the member states changes at the same time. It's not 
like the US where it ripples across the timezones, so the differences 
vary during the change. It all happens in one go.

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 8:22 AM MRAB  wrote:
>
> [snip]
> In the EU, DST in the member states changes at the same time. It's not
> like the US where it ripples across the timezones, so the differences
> vary during the change. It all happens in one go.
>

Ah, good to know. I think that actually makes a lot of sense; in the
US, they try to let everyone pretend that the rest of the world
doesn't exist ("we always change at 2AM"), but in Europe, they try to
synchronize for the convenience of commerce ("everyone changes at 1AM
UTC").

A quick browse of Wikipedia suggests that some European countries
(outside of the EU, which mandates DST transitions) have constant
year-round UTC offsets. In theory, there could be a non-EU country
that observes DST with different dates, but I can't find any examples.
Here's hoping, hehe.

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

Re: urgent

[Barry]



> On 31 Aug 2021, at 16:53, jak  wrote:
> 
> Il 31/08/2021 03:05, Python ha scritto:
>> Hari wrote:
>>> i was download ur python software but it is like boring user interface for
>>> me like young student to learn ,can u have any updates?
>> God, let me die please...
> 
> Oh no, please don't speak in that way ... evidently now that python has
> reached its tenth version its prompt is a little boring. It may need to
> be replaced. You could open a competition notice to vote on the new
> prompt. I would vote for:
> 
> :^P>

The big problem with >>> is that it means a third level quote in email clients.
So when people cut-n-paste REPL output it’s formatted badly by email clients.
A prompt that avoided that issue would be nice.

>>> print(“this is not a quoted reply”)

Barry

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

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

Re: urgent

[Chris Angelico]

On Wed, Sep 1, 2021 at 9:03 AM Barry  wrote:
>
>
>
> > On 31 Aug 2021, at 16:53, jak  wrote:
> >
> > Il 31/08/2021 03:05, Python ha scritto:
> >> Hari wrote:
> >>> i was download ur python software but it is like boring user interface for
> >>> me like young student to learn ,can u have any updates?
> >> God, let me die please...
> >
> > Oh no, please don't speak in that way ... evidently now that python has
> > reached its tenth version its prompt is a little boring. It may need to
> > be replaced. You could open a competition notice to vote on the new
> > prompt. I would vote for:
> >
> > :^P>
>
> The big problem with >>> is that it means a third level quote in email 
> clients.
> So when people cut-n-paste REPL output it’s formatted badly by email clients.
> A prompt that avoided that issue would be nice.
>
> >>> print(“this is not a quoted reply”)
>

Welp, gonna have to convince people that the Python 3000 decision
needs to be reversed :)

https://www.python.org/dev/peps/pep-3099/#interactive-interpreter

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[dn via Python-list]

On 01/09/2021 09.13, Chris Angelico wrote:
> On Wed, Sep 1, 2021 at 6:38 AM dn via Python-list
>  wrote:
>>> Yeah. I do recommend making good use of the IANA tzinfo database
>>> though (especially since Python 3.9 made that a bit easier to access),
>>> as it's usually easier to get people to tell you what city/state
>>> they're in, rather than whether daylight time will be active or not.
>>> (It might take a little bit of translation to figure out that, for
>>> instance, New Brunswick CA is America/Halifax, but that's not too hard
>>> usually.) Letting tzinfo do all the work means you don't have to fret
>>> about anyone's daylight saving transition dates, or whether they've
>>> decided to change their clocks by half an hour to be different from
>>> Japan's clocks, or to have DST not applicable during Ramadan, or to
>>> have double DST, or double-negative DST. And yes, those are all real,
>>> because you can't make up anything as insane as actual clock politics.
>>
>> So, given that it is a NUMERIC calculation, dispense with "New Brunswick
>> CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
>> Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
>> time numerically: "17:00-3"
>>
>> Given that, someone at UTC-4 knows that his/her rendez-vous will be
>> "1600", and I can figure it to be "0800" for me:
>>
>> 1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
>> and
>> 1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
>>   rounding to 24hrs: 08:00
>>   (the next day)
> 
> No, that's not reliable... because of that abomination called Daylight
> Saving Time. Since I used New Brunswick, and since she's just gone
> online, I'll use a specific example:
> 
> DeviCat livestreams at 6pm every Tuesday (and other times, but I'm
> going to focus on a weekly event here). Since she lives in NB, Canada,
> she defines that time by what IANA refers to as America/Halifax.
> 
> I want to be there at the start of each stream, since I'm one of her
> moderators. But I live in a suburb of Melbourne - my clock shows what
> IANA calls Australia/Melbourne.
> 
> To turn this into a purely mathematical calculation, you have to know
> exactly when she will go on or off DST, and when I will go on or off.
> Trying to turn it into an offset is going to fail badly as soon as you
> talk about "next Tuesday" and one of us is shifting DST this weekend.
> 
> That's why it's better to let Python (or something) handle the whole
> thing. Don't concern yourself with exactly what the hour differences
> are, or which way DST is going, or anything; just convert Halifax time
> to Melbourne time.

OK, I admit it: I am so lazy that I don't use my fingers (nor my toes!)
but expect my poor, over-worked (and under-paid) computer to calculate
it all for me...


I should have split the earlier explanation of two calculations, more
clearly:

Devicat can declare the start as "6pm" ("localisation")
and state that the time-zone is UTC-3
- or as @MRAB suggested, translate it to "21:00 UTC"
("internationalisation")

You (@Chris) then perform the second-half calculation, by adjusting the
UTC-value to your time-zone.

- and were I to attend, would personalise ("localise") the time
similarly - but using my locality's (different) UTC-offset.


I agree, the idea of 'Summer Time' is a thorough pain - even more-so
when the host publishes in local-time but forgets that there will be a
"spring forward" or "fall back" between the time of publication and the
meeting-date!

[the song says "Summer Time, and the living is easy". Unfortunately,
Ella Fitzgerald isn't here to wrap her head around the problem, so I
guess it's up to us...]

Once again, it is a localisation/internationalisation problem. Why would
you/I know, if and when, New Brunswick moves in/out of Summer Time? As
described, it is another 'big ball of mud'.

Far better to have the local deal with 'local issues', and for us to
handle our own (time-zone) problems!
(why should Devicat concern herself with MLB-based issues, or NZST, or
wherever and etc?)

[BTW: welcome to the first day of 'summer'!]


Accordingly, when the Néo-Brunswickoise publishes "6pm", all the locals
will be happy.

If she adds UTC, or the locally-applicable UTC-offset (for Summer-Time,
or not), the international community can make their own and personal
arrangements, without winding-through the opaque and arcane
seasonal-adjustments described!

Plus the virtue(?) of using International Standards!


>> For many of us, the mental-calculations are relatively easy to manage.
>> For Python the code is trivial. Computation is easier than terminology
>> 'translation' (particularly when one has to research the terms first!
>> - did you know what "ADT" meant?)
> 
> I asked DeviCat what country and province ("state" in other regions)
> she lived in, and then confirmed with her that Halifax time was what

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[MRAB]

On 2021-08-31 23:31, Chris Angelico wrote:

On Wed, Sep 1, 2021 at 8:22 AM MRAB  wrote:


[snip]
In the EU, DST in the member states changes at the same time. It's not
like the US where it ripples across the timezones, so the differences
vary during the change. It all happens in one go.



Ah, good to know. I think that actually makes a lot of sense; in the
US, they try to let everyone pretend that the rest of the world
doesn't exist ("we always change at 2AM"), but in Europe, they try to
synchronize for the convenience of commerce ("everyone changes at 1AM
UTC").

A quick browse of Wikipedia suggests that some European countries
(outside of the EU, which mandates DST transitions) have constant
year-round UTC offsets. In theory, there could be a non-EU country
that observes DST with different dates, but I can't find any examples.
Here's hoping, hehe.

It goes forwards on the last Sunday of March and back on the last Sunday 
of October.

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Wed, Sep 1, 2021 at 9:20 AM dn via Python-list
 wrote:
>
> On 01/09/2021 09.13, Chris Angelico wrote:
> > On Wed, Sep 1, 2021 at 6:38 AM dn via Python-list
> >  wrote:
> >>> Yeah. I do recommend making good use of the IANA tzinfo database
> >>> though (especially since Python 3.9 made that a bit easier to access),
> >>> as it's usually easier to get people to tell you what city/state
> >>> they're in, rather than whether daylight time will be active or not.
> >>> (It might take a little bit of translation to figure out that, for
> >>> instance, New Brunswick CA is America/Halifax, but that's not too hard
> >>> usually.) Letting tzinfo do all the work means you don't have to fret
> >>> about anyone's daylight saving transition dates, or whether they've
> >>> decided to change their clocks by half an hour to be different from
> >>> Japan's clocks, or to have DST not applicable during Ramadan, or to
> >>> have double DST, or double-negative DST. And yes, those are all real,
> >>> because you can't make up anything as insane as actual clock politics.
> >>
> >> So, given that it is a NUMERIC calculation, dispense with "New Brunswick
> >> CA is America/Halifax"; and avoid "Atlantic Time", "Atlantic Standard
> >> Time", "Atlantic Daylight Time", "AT", "ADT", or "AST", and express the
> >> time numerically: "17:00-3"
> >>
> >> Given that, someone at UTC-4 knows that his/her rendez-vous will be
> >> "1600", and I can figure it to be "0800" for me:
> >>
> >> 1700 - -3 = 20:00 (to calculate UTC), then UTC-4 = 16:00
> >> and
> >> 1700 - -3 = 20:00 (to calculate UTC), then UTC+12 = 32:00,
> >>   rounding to 24hrs: 08:00
> >>   (the next day)
> >
> > No, that's not reliable... because of that abomination called Daylight
> > Saving Time. Since I used New Brunswick, and since she's just gone
> > online, I'll use a specific example:
> >
> > DeviCat livestreams at 6pm every Tuesday (and other times, but I'm
> > going to focus on a weekly event here). Since she lives in NB, Canada,
> > she defines that time by what IANA refers to as America/Halifax.
> >
> > I want to be there at the start of each stream, since I'm one of her
> > moderators. But I live in a suburb of Melbourne - my clock shows what
> > IANA calls Australia/Melbourne.
> >
> > To turn this into a purely mathematical calculation, you have to know
> > exactly when she will go on or off DST, and when I will go on or off.
> > Trying to turn it into an offset is going to fail badly as soon as you
> > talk about "next Tuesday" and one of us is shifting DST this weekend.
> >
> > That's why it's better to let Python (or something) handle the whole
> > thing. Don't concern yourself with exactly what the hour differences
> > are, or which way DST is going, or anything; just convert Halifax time
> > to Melbourne time.
>
> OK, I admit it: I am so lazy that I don't use my fingers (nor my toes!)
> but expect my poor, over-worked (and under-paid) computer to calculate
> it all for me...
>
>
> I should have split the earlier explanation of two calculations, more
> clearly:
>
> Devicat can declare the start as "6pm" ("localisation")
> and state that the time-zone is UTC-3
> - or as @MRAB suggested, translate it to "21:00 UTC"
> ("internationalisation")
>
> You (@Chris) then perform the second-half calculation, by adjusting the
> UTC-value to your time-zone.
>
> - and were I to attend, would personalise ("localise") the time
> similarly - but using my locality's (different) UTC-offset.

Gotcha gotcha. Unfortunately that, while theoretically easier, is not
correct; she streams at 6pm every week, which means that the UTC time
is *different* in June and December.

> I agree, the idea of 'Summer Time' is a thorough pain - even more-so
> when the host publishes in local-time but forgets that there will be a
> "spring forward" or "fall back" between the time of publication and the
> meeting-date!

Right. Which is basically guaranteed when it's a recurring event.

> Accordingly, when the Néo-Brunswickoise publishes "6pm", all the locals
> will be happy.
>
> If she adds UTC, or the locally-applicable UTC-offset (for Summer-Time,
> or not), the international community can make their own and personal
> arrangements, without winding-through the opaque and arcane
> seasonal-adjustments described!
>
> Plus the virtue(?) of using International Standards!

She'd have to either specify two different UTC times, or two different
local times. Instead, it's safer to just have her publish one local
time (since that's how she's defining things), and let us all convert
directly to our own timezones every time.

> The "New Brunswick" in Canada is quite close to the "New Brunswick" in
> New Jersey (USA) - in physical distance, but the two are in distinct
> time-zones. (Yes, you did say "CA", but easily 'missed' - by author and
> reader alike)

Fair point. I'm not familiar with New Brunswick, New Je

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[dn via Python-list]

> Yeah. And if you think you've heard it all, sign up for the
> tzdata-announce mailing list and wait for the next phenomenon. I think
> Egypt (Africa/Cairo) is currently in the lead for weirdest timezone
> change, for (with short notice) announcing that they'd have DST during
> summer but not during Ramadan. Since "summer" is defined by a solar
> calendar and "Ramadan" is defined by a lunar calendar, that means the
> DST exclusion might happen entirely in winter (no effect), at one end
> or other of summer (shortens DST, just changes the dates), or in the
> middle of summer (DST on, DST off, DST on, DST off, in a single year).
> But they will, at some point, be eclipsed by an even more bizarre
> timezone change. I don't dare try to predict what will happen, because
> I know that the reality will be even worse


Similar to the situation where a few US cities maintain a different
time-zone to the rest of the(ir) state, our refinery (in the Middle
East) maintained just such a Ramadan-clock. I think such might be quite
a common practice (which I'll describe, below).

When considered, and motivation aside, it's not so very different from
schemes enabling employees to choose their personal start-time (usually
within a range, eg "glide time"), ideas to reduce 'rush hour' grid-locks
by spreading commuter start/finish times, etc.


At the refinery (computer center), we started one (or was it two) hours
earlier that usual - as close to dawn as possible, ie the beginning of
the daily fast.

"Western employees" could take regular breaks, and usually 'disappeared'
for 'midday meal', somewhere around 1030~1130.

Muslim employees had no breaks. In lieu, they went home early - to be
able to sleep. Later came sunset-prayers, and thereafter
breaking-the-fast. Typically, there would be activities, and more meals,
during the night.

Meantime, the non-Muslims maintained a short 'afternoon shift', going
home commensurately early.

Others in the community were totally confused: "Why didn't you answer
your phone yesterday afternoon?", "a meeting at 0700 - you must be
joking!", etc. The pattern and predictability were broken!


I thought it was a fabulous idea, actually leaving the office on-time
(for a change), and heading straight down to the beach for some
wind-surfing...

That said, it really messed with your head. People staggered-in and
managed little output first-thing. (need I say more?)

At a more amusing level: my door was literally always-open, and because
my office was at the end of a corridor, colleagues required only a
glance to see if I was 'available'. The door only closed for
personal/confidential discussions or when I was 'out' - except during
Ramadan when I didn't want to insult anyone by drinking tea, effectively
in-public. So, when the door was closed for long periods, this confused
my staff. Indeed, I would often be asked "where have you been?" when I'd
been working-away at my desk all-along, but simply hadn't got up to open
the door once 'the coast was clear'. Life's rich tapestry...

In my case, I blame "Ramadan-hours" for 'flipping the switch' (in my
head) and turning a late-night owl, and stereotypical techie/hacker;
into an 'early bird'. Ironically such serves me well today - dealing
with clients and colleagues on the other side of the planet, who much
prefer me to wake-early, so that they don't have to interrupt their
evenings at home...
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[dn via Python-list]

On 01/09/2021 11.27, MRAB wrote:
> On 2021-08-31 23:31, Chris Angelico wrote:
>> On Wed, Sep 1, 2021 at 8:22 AM MRAB  wrote:
>>>
>>> [snip]
>>> In the EU, DST in the member states changes at the same time. It's not
>>> like the US where it ripples across the timezones, so the differences
>>> vary during the change. It all happens in one go.
>>>
>>
>> Ah, good to know. I think that actually makes a lot of sense; in the
>> US, they try to let everyone pretend that the rest of the world
>> doesn't exist ("we always change at 2AM"), but in Europe, they try to
>> synchronize for the convenience of commerce ("everyone changes at 1AM
>> UTC").
>>
>> A quick browse of Wikipedia suggests that some European countries
>> (outside of the EU, which mandates DST transitions) have constant
>> year-round UTC offsets. In theory, there could be a non-EU country
>> that observes DST with different dates, but I can't find any examples.
>> Here's hoping, hehe.
>>
> It goes forwards on the last Sunday of March and back on the last Sunday
> of October.

and @Chris' point about the lack of synchronisation:

«
Daylight saving starts each year at 2am on the last Sunday in September,
and ends at 3am on the first Sunday in April.

Daylight saving starts  Daylight saving ends
26 September 2021   3 April 2022
»
https://www.govt.nz/browse/recreation-and-the-environment/daylight-saving/


Have learned something new about my adopted-country today! Apparently
New Zealand was once one of those half-hour-out countries (until 1946).
From when no "Daylight Saving time" was recognised. In 1974 a trial took
place, and after public debate, the idea extended - continuing today:
https://www.govt.nz/browse/recreation-and-the-environment/daylight-saving/history-of-daylight-saving-in-nz/


To explain the rationale for "Daylight Saving", ie "Summer Time":
«
The 2008 survey found that 82% of New Zealanders approved of the 2007
extension to the period of daylight saving time.

The rationale for changing the time over the summer months is that more
sunlight hours will fall in the early morning if standard time is
applied year round. In summer, these early morning sunlight hours are
seen as being wasted as many people are asleep at that time. If the
sunlight hours are shifted to the evening, by way of daylight saving
time, they are more useful.
»
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: urgent (actually NOT urgent at all.)

[Avi Gross via Python-list]

This is a bit sillier then some other discussions here!

There are many programs (especially back when more command-line programs were 
used) that presented default prompts like "$" and many or most of them let you 
over-ride it.

Can someone tell this person that if >>> is not pleasing, they can do something 
like:

import sys
sys.ps1 = "what do you wish Mistress? -=> "

And this can be set per session or perhaps across all accounts in an 
installation as a default?

Some people focus on minutiae rather than either accept a language as being 
what it is, or finding a different way that meets their needs.

I occasionally have made the prompt empty for a while so I can more easily do 
cut and paste from it. All that is needed for some is to make whatever prompt 
be somewhat unique among the other prompts they normally face. Sure, on some 
screens there are ways to add color or even odd characters and  graphics to 
some prompts but who needs sexy?

Realistically, many of us do so much of the programming elsewhere as in some 
editor or environment, and especially a language like python where indentation 
levels are strictly a part of the language.


-Original Message-
From: Python-list  On 
Behalf Of Barry
Sent: Tuesday, August 31, 2021 7:02 PM
Cc: Python-list@python.org
Subject: Re: urgent



> On 31 Aug 2021, at 16:53, jak  wrote:
> 
> Il 31/08/2021 03:05, Python ha scritto:
>> Hari wrote:
>>> i was download ur python software but it is like boring user 
>>> interface for me like young student to learn ,can u have any updates?
>> God, let me die please...
> 
> Oh no, please don't speak in that way ... evidently now that python 
> has reached its tenth version its prompt is a little boring. It may 
> need to be replaced. You could open a competition notice to vote on 
> the new prompt. I would vote for:
> 
> :^P>

The big problem with >>> is that it means a third level quote in email clients.
So when people cut-n-paste REPL output it’s formatted badly by email clients.
A prompt that avoided that issue would be nice.

>>> print(“this is not a quoted reply”)

Barry

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

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

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

Re: Struggling to understand timedelta rpesentation when applying an offset for an hour earlier - why is days = -1?

[Dennis Lee Bieber]

On Tue, 31 Aug 2021 03:59:52 -0700 (PDT), dcs3spp via Python-list
 declaimed the following:


>I cannot understand why the resultant datetime.timedelta is days=-1, 
>seconds=82800 (23 hours) .
>

Read the documentation...
https://docs.python.org/3/library/datetime.html#timedelta-objects


>Why is it not an hour earlier as seconds=-3600? Why is days = -1 when the 
>resultant calculated date is the same, year, day, month??

"""
and days, seconds and microseconds are then normalized so that the
representation is unique, with

0 <= microseconds < 100

0 <= seconds < 3600*24 (the number of seconds in one day)

-9 <= days <= 9
"""

Note that microseconds and seconds are ALWAYS normalized to be a positive
integer. So your input on -3600 is normalized to +82800 from the previous
day.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/

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

Re: urgent

[Grant Edwards]

On 2021-08-29, Hari  wrote:

> i was download ur python software but it is like boring user
> interface for me like young student to learn ,can u have any
> updates?

Check the calendar, it must be September again...

Well, almost.

-- 
Grant Edwards   grant.b.edwardsYow! Did I do an INCORRECT
  at   THING??
  gmail.com

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

Re: Create a real-time interactive TUI using Python.

[Dennis Lee Bieber]

On Tue, 31 Aug 2021 06:12:42 -0700 (PDT), "hongy...@gmail.com"
 declaimed the following:

>I want to know whether python can be used to create real-time interactive TUI, 
>as hstr [1] does.
>

Most of these utilities appear to rely upon embedding commands into the
OS SHELL prompt. You could embed pretty much anything to be run as part of
the prompt display.
https://github.com/dvorka/hstr/blob/master/CONFIGURATION.md#bash-history-settings

Since source for HSTR is available, nothing prevents you from recoding
everything in Python -- though I'm fairly certain Python may be a bit
slower unless you can take advantage of compiled C libraries (regex,
perhaps). Based upon the animated GIF, you'll have to master the curses
library from Python.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/

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

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Michael F. Stemper]

On 31/08/2021 16.13, Chris Angelico wrote:



But ultimately, it all just means that timezones are too hard for
humans to handle, and we MUST handle them using IANA's database. It is
the only way.


Tom Scott makes this point quite strongly on Computerphile:



And amusingly.

--
Michael F. Stemper
Always remember that you are unique. Just like everyone else.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Create a real-time interactive TUI using Python.

[hongy...@gmail.com]

On Wednesday, September 1, 2021 at 12:49:51 AM UTC+8, Chris Angelico wrote:
> On Wed, Sep 1, 2021 at 1:59 AM hongy...@gmail.com  wrote: 
> > 
> > I want to know whether python can be used to create real-time interactive 
> > TUI, as hstr [1] does. 
> > 
> > [1] https://github.com/dvorka/hstr 
> >
> Yes. 

The following are some python TUI framework libraries/projects I have 
discovered so far:

https://github.com/pfalcon/picotui
https://github.com/peterbrittain/asciimatics
https://github.com/bczsalba/pytermgui
https://github.com/GeorgeFilipkin/pulsemixer
https://github.com/jwlodek/py_cui
https://github.com/saulpw/visidata
https://github.com/willmcgugan/textual
https://github.com/urwid/urwid

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

Re: Create a real-time interactive TUI using Python.

[Christian Gollwitzer]

Am 31.08.21 um 18:49 schrieb Chris Angelico:

On Wed, Sep 1, 2021 at 1:59 AM hongy...@gmail.com  wrote:


I want to know whether python can be used to create real-time interactive TUI, 
as hstr [1] does.

[1] https://github.com/dvorka/hstr



Yes.


I think he also would like to know, how to achieve this ;)

This kind of interface is usually done with the "curses"-library. There 
is a Python version of it, see e.g. here


https://docs.python.org/3/howto/curses.html


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

Request for argmax(list) and argmin(list)

[ABCCDE921]

I dont want to import numpy

argmax(list) 
   returns index of (left most) max element

 argmin(list)
   returns index of (left most) min element
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Request for argmax(list) and argmin(list)

[Paul Bryan]

Why not:

>>> l = [1, 3, 5, 9, 2, 7]
>>> l.index(max(l))
3
>>> l.index(min(l))
0

On Tue, 2021-08-31 at 21:25 -0700, ABCCDE921 wrote:
> I dont want to import numpy
> 
> argmax(list) 
>    returns index of (left most) max element
> 
>  argmin(list)
>    returns index of (left most) min element

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