Re: count consecutive elements

[Peter Otten]

On 19/01/2021 04:45, Bischoop wrote:


I sat to it again and solved it.


Congratulations!

> lil = tuple(set(s)) # list of characters in s
>
> li=[0,0,0,0,0,0]  # list for counted repeats

I see a minor problem here. What happens if s contains more than len(li)
characters?


import timeit


Since you seem interested in performance: imagine that the input is a
very long string. Let's call the length N.

How often do you iterate over its characters?
How often does Tim's solution?
--
https://mail.python.org/mailman/listinfo/python-list

Re: count consecutive elements

[Bischoop]

On 2021-01-19, Peter Otten <__pete...@web.de> wrote:
> On 19/01/2021 04:45, Bischoop wrote:
>
>> I sat to it again and solved it.
>
> Congratulations!
>
> > lil = tuple(set(s)) # list of characters in s
> >
> > li=[0,0,0,0,0,0]  # list for counted repeats
>
> I see a minor problem here. What happens if s contains more than len(li) 
> characters?
>

Thanks, I've created it when came to idea how to solve the problem and
then forgot that part, will have to update it with two additional line
of code.

>> import timeit
>
> Since you seem interested in performance: imagine that the input is a 
> very long string. Let's call the length N.
>
> How often do you iterate over its characters?
>

Does it take time :-) I actually left it because seen guy in thread
were comparing their time results, I'm pretty much aware that mine
solution is time consuming and there are better ways to do it but
I wanted to finish what I started without any additional libraries
like itertools etc in the way that my knowledge allows. The idea with
for this tuple just came up in a first seconds when I look at that
and was not bothering about time or performance especially that later
on as you seen I had different problem to solve and which took me quite
a time and when I look at it today I think how couldn't I came with it
earlier and let myself stuck on it.

I'm happy that despite I've asked here I've finish it practically wthout
additional help and yeah ( Thanks to Stefan who just pointed me to look
at it from different prespective instead pointing what was wrong),
I'll iterate here n = x [x for x in lil], with big string it can make 
difference. Now, when you asked me that question I came indeed for better
idea to do this. One loop during which I can append character if not in lil.

> How often does Tim's solution?

oh here Im stuck and dont understand what you mean?

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

Re: count consecutive elements

[Peter Otten]

On 19/01/2021 10:42, Bischoop wrote:

On 2021-01-19, Peter Otten <__pete...@web.de> wrote:

On 19/01/2021 04:45, Bischoop wrote:


I sat to it again and solved it.


Congratulations!


lil = tuple(set(s)) # list of characters in s

li=[0,0,0,0,0,0]  # list for counted repeats


I see a minor problem here. What happens if s contains more than len(li)
characters?



Thanks, I've created it when came to idea how to solve the problem and
then forgot that part, will have to update it with two additional line
of code.


import timeit


Since you seem interested in performance: imagine that the input is a
very long string. Let's call the length N.

How often do you iterate over its characters?



Does it take time :-) I actually left it because seen guy in thread
were comparing their time results, I'm pretty much aware that mine
solution is time consuming and there are better ways to do it but
I wanted to finish what I started without any additional libraries
like itertools etc in the way that my knowledge allows. The idea with
for this tuple just came up in a first seconds when I look at that
and was not bothering about time or performance especially that later
on as you seen I had different problem to solve and which took me quite
a time and when I look at it today I think how couldn't I came with it
earlier and let myself stuck on it.

I'm happy that despite I've asked here I've finish it practically wthout
additional help and yeah ( Thanks to Stefan who just pointed me to look
at it from different prespective instead pointing what was wrong),
I'll iterate here n = x [x for x in lil], with big string it can make
difference. Now, when you asked me that question I came indeed for better
idea to do this. One loop during which I can append character if not in lil.


How often does Tim's solution?


oh here Im stuck and dont understand what you mean?


[Tim Chase]


  def consecutive_counter(seq):
  # I'm not sure if there's something
  # like this already in itertools
  cur = nada = object()
  count = 0
  for x in seq:
  if x == cur:
  count += 1
  else:
  if cur is not nada:
  yield cur, count
  cur = x
  count = 1
  if cur is not nada:
  yield cur, count

  def longest(seq):
  results = []
  biggest = 0
  for item, count in seq:
  if count > biggest:
  results = [item]
  biggest = count
  elif count == biggest:
  results.append(item)
  return results, biggest



Tim's code iterates over the string once whereas you iterate multiple
times. While this is mainly a question of elegance performance is
affected when you have *nested* loops:


for i in lil:
c = 0
h= lil.index(i)
for letter in s:


If you are unlucky and run into a string with 1000 different characters
the code in your inner loop will execute 1000*1000 times while Tim's
will run 1000 times. This is called O(N*N) and O(N).

Not all loops are obvious,


lil.index(letter)


contains another loop, and you now have O(N*N*N) behavior.

This is the worst case, usually the alphabet (li1) will be smaller, but
avoiding nested loops when possible is still a good habit to get into.

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

Re: Python not Running

[MRAB]

On 2021-01-19 03:26, Mladen Gogala via Python-list wrote:
[snip]


Since you're most probably using Winduhs, use regedit and modify your PATH
variable. Your python will be in c:\Program Files if you installed 64 bit
version, which you should have done. Otherwise, it will be in C:\Program
Files(x86). Your "idle" program will be in your "start menu" which came
back in Winduhs 10. You would probably never have guessed, but I'm not
particularly fond of Winduhs.


[snip]

I wouldn't use regedit to edit the PATH variable. It's an environment 
variable, so I'd use the System Properties dialog (the Advanced tab).

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

Re: Exploring terminfo

[Grant Edwards]

On 2021-01-19, Greg Ewing  wrote:
> On 19/01/21 2:34 pm, Alan Gauld wrote:
>> To be fair that's a limitation of the C curses library. putp() is a
>> wrapper around tputs() even there, and you can't change what it does.
>> The gap in the curses module is that it doesn't offer the tputs()
>> option as an alternative.
>
> Seems to me it would be useful to have something that returns
> what tputs() would have output, as a string, so you can send it
> where you want.

I tried to do that using ctypes by passing tputs() a Python "putc"
callback, but I couldn't get it to work (the callback never got
called).

--
Grant



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

PyConBY (Belarus) 2021 Online. Call for Proposals

[Mikalai Saskavets]

Hi All!

I am on a program committee of the PyCon Belarus team.

Our team is happy to announce that PyCon Belarus 2021 https://by.pycon.org/
will be held on March 13. We made it online and free for everyone. 500+
Python developers of all levels will join us remotely.

Call for Proposals is now open and we are accepting submissions till
February 12. Please find all the details about the CFP here:
https://forms.gle/fNsJbwU53kjGhsrh8


Warmest regards,
Mikalai Saskavets
PyCon Belarus Program Committee Co-Chair
Engineering Manager at iTechArt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Exploring terminfo

[Grant Edwards]

On 2021-01-19, Alan Gauld via Python-list  wrote:
> On 18/01/2021 22:14, Random832 wrote:
>> On Fri, Jan 15, 2021, at 13:36, Alan Gauld via Python-list wrote:
>>> That could make a big difference, the putp() function specifically
>>> states that it writes to stdout.
>> 
>> I think there is a reasonable argument that this is a deficiency of
>> the curses module.
>> 
>> I think that the curses module should ..
>> B) expose a version of putp that uses pthon's stdout[.buffer].write
>> rather than C's putchar.
>
> To be fair that's a limitation of the C curses library. putp() is a
> wrapper around tputs() even there, and you can't change what it does.
> The gap in the curses module is that it doesn't offer the tputs()
> option as an alternative.

If the curses module provided a tputs binding, then the user could
write a useful putp(), or better yet a function that just does the
padding and returns a new bytestring.

> I've been using curses (C and python) for nearly 30 years and
> this is the first time I've ever used the tiXXX functions,  and it
> was mainly just out of curiosity rather than real need.

Same here.

--
Grant




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

Re: Exploring terminfo

[Eli the Bearded]

In comp.lang.python, Greg Ewing   wrote:
> On 18/01/21 3:34 am, Alan Gauld wrote:
>> The problem is terminfo is not really part of curses.
>> Curses is built on top of terminfo.
> As far as I can tell from the man pages, terminfo itself
> is just a file format. The only programmatic interfaces I
> can find for it *are* part of curses:

Putting my Unix hat on, curses is a "friendly" library around creating
text-windowed applications. Programs like mutt use curses rather than
raw terminal operations, programs like vi use raw terminal operations.
Either curses or raw terminal operations will (should) consult a
terminal capabilities database to figure out what can be done and how to
do it. The two competing database formats for that are termcap and
terminfo, where terminfo is the newer, better one.

Termcap used a single large text file for all terminals types.
Terminfo uses a directory tree full of small files, one per type.

I'm pretty sure both include the ability to say something along the
lines of "start with this one terminal, and then change these bits".
So that starts to get complicated without a library. Or maybe I'm wrong,
and vi uses curses. I'm not really sure how vi reads the term info files.

Okay, checking the source to the only vi I have lying around[*], it uses
a few curses calls, apparently only these:

int tgetent(char *bp, const char *name);
int tgetflag(char *id);
int tgetnum(char *id);
char *tgetstr(char *id, char **area);
char *tgoto(const char *cap, int col, int row);
int tputs(const char *str, int affcnt, int (*putc)(int));

My local manpage calles this set the "direct curses interface to the
terminfo capability database" whereas things I think of as "curses"
programs use calls like:

WINDOW *initscr(void);
int cbreak(void);
int start_color(void);
int noecho(void);
int move(int y, int x);
int attr_set(attr_t attrs, short pair, void *opts);
int getch(void);
int addch(const chtype ch);
int printw(const char *fmt, ...);

The vi method relies on the programmer knowing what attributes are
wanted and how to use them, and how to use alternatives when the
first choices aren't provided. The curses method relies on the programmer
knowing which of a hundred different library functions to use for any
given output. :^)

[*] It's ex-1.1, an "heirloom" source package that has possibly been
brushed up just enough to compile on a modern system. ex-1.1 is by
most reckoning, the first vi. It won't start in vi mode though, you
need to run ex, then begin the visual mode. It is recongizable as vi
to me, but a somewhat different experience.

Elijah
--
has modified C curses programs, but not written one from scratch
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Exploring terminfo

[Grant Edwards]

On 2021-01-19, Eli the Bearded <*@eli.users.panix.com> wrote:

> Putting my Unix hat on, curses is a "friendly" library around creating
> text-windowed applications. Programs like mutt use curses rather than
> raw terminal operations, programs like vi use raw terminal operations.
> Either curses or raw terminal operations will (should) consult a
> terminal capabilities database to figure out what can be done and how to
> do it. The two competing database formats for that are termcap and
> terminfo, where terminfo is the newer, better one.

Back in the day, weren't the termcap/terminfo libraries maintained and
installed seperately from curses?  I would have sworn that only a few
years ago terminfo and ncurses libraries were seperate -- though
recently both were provided by ncurses, IIRC.

[...]

> Okay, checking the source to the only vi I have lying around[*], it uses
> a few curses calls, apparently only these:
>
> int tgetent(char *bp, const char *name);
> int tgetflag(char *id);
> int tgetnum(char *id);
> char *tgetstr(char *id, char **area);
> char *tgoto(const char *cap, int col, int row);
> int tputs(const char *str, int affcnt, int (*putc)(int));

In my mind, those are curses library calls, they're termcap/terminfo
library calls. [I can't recall whether terminfo and termcap APIs were
compatible or not.]

> My local manpage calles this set the "direct curses interface to the
> terminfo capability database" whereas things I think of as "curses"
> programs use calls like:
>
> WINDOW *initscr(void);
> int cbreak(void);
> int start_color(void);
> int noecho(void);
> int move(int y, int x);
> int attr_set(attr_t attrs, short pair, void *opts);
> int getch(void);
> int addch(const chtype ch);
> int printw(const char *fmt, ...);

Exactly. _Those_ are curses library calls.

--
Grant


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

Re: Exploring terminfo

[Grant Edwards]

On 2021-01-19, Grant Edwards  wrote:
>>
>> int tgetent(char *bp, const char *name);
>> int tgetflag(char *id);
>> int tgetnum(char *id);
>> char *tgetstr(char *id, char **area);
>> char *tgoto(const char *cap, int col, int row);
>> int tputs(const char *str, int affcnt, int (*putc)(int));
>
> In my mind, those are curses library calls, they're termcap/terminfo
  aren't curses 

Sorry about that...


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

[ANN] PyYAML-5.4 Released

[Matt Davis]

=
Announcing PyYAML-5.4
=

A new release of PyYAML is now available:
https://github.com/yaml/pyyaml/releases/tag/5.4

This release contains a security fix for CVE-2020-14343. It removes the
python/module, python/object, and python/object/new tags from the
FullLoader. YAML that uses these tags must be loaded by UnsafeLoader, or a
custom loader that has explicitly enabled them.

This release also adds Python wheels for manylinux1 (x86_64) and MacOS
(x86_64) with the libyaml extension included (built on libyaml 0.2.5).

PyYAML 5.4 will be the last release to support Python 2.7 (except for
possible critical bug fix releases).


Changes
===

* https://github.com/yaml/pyyaml/pull/407 -- build modernization, remove
distutils, fix metadata, build wheels, CI to GHA
* https://github.com/yaml/pyyaml/pull/472 -- fix for CVE-2020-14343, moves
arbitrary python tags to UnsafeLoader
* https://github.com/yaml/pyyaml/pull/441 -- fix memory leak in implicit
resolver setup
* https://github.com/yaml/pyyaml/pull/392 -- fix py2 copy support for
timezone objects
* https://github.com/yaml/pyyaml/pull/378 -- fix compatibility with Jython


Resources
=

PyYAML IRC Channel: #pyyaml on irc.freenode.net
PyYAML homepage: https://github.com/yaml/pyyaml
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation
Source and binary installers: https://pypi.org/project/PyYAML/
GitHub repository: https://github.com/yaml/pyyaml/
Bug tracking: https://github.com/yaml/pyyaml/issues

YAML homepage: http://yaml.org/
YAML-core mailing list:
http://lists.sourceforge.net/lists/listinfo/yaml-core


About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages. PyYAML is a YAML parser and emitter
for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages. PyYAML
supports standard YAML tags and provides Python-specific tags that allow to
represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex configuration
files to object serialization and persistence.


Example
===

```
>>> import yaml

>>> yaml.full_load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: https://github.com/yaml/pyyaml
... keywords: [YAML, serialization, configuration, persistence, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistence',
'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print(yaml.dump(_))
name: PyYAML
homepage: https://github.com/yaml/pyyaml
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistence, pickle]
```

Maintainers
===

The following people are currently responsible for maintaining PyYAML:

* Ingy döt Net
* Matt Davis

and many thanks to all who have contributed!
See: https://github.com/yaml/pyyaml/pulls


Copyright
=

Copyright (c) 2017-2021 Ingy döt Net 
Copyright (c) 2006-2016 Kirill Simonov 

The PyYAML module was written by Kirill Simonov .
It is currently maintained by the YAML and Python communities.

PyYAML is released under the MIT license.
See the file LICENSE for more details.
-- 
https://mail.python.org/mailman/listinfo/python-list

Force Python ast to emit lines no longer than $length

[Samuel Marks]

I've written a library that works at the ast level. Sometimes the
generated output goes over the linter line length limit.

"foo_bar_can_haz_foo_bar_can_haz_foo_bar_can_haz_foo_bar_can_haz_foo_bar_can_haz_foo_bar_can_haz"

How do I generate this kind of code instead?

"foo_bar_can_haz_foo_bar_can_haz_foo_bar_can_haz_"
"foo_bar_can_haz_foo_bar_can_haz_foo_bar_can_haz"

(also happy with the \ and parenthesised variants) [cross-posted:
stackoverflow.com/q/65800797]

The only thing I can think of doing—retaining support for 3.6, 3.7,
3.8, 3.9, and 3.10a4—is to contribute to both astor and the builtin
ast.unparse…
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: open sentinel-2image python

[Mladen Gogala via Python-list]

On Sun, 17 Jan 2021 18:01:26 +, MRAB wrote:

> On 2021-01-17 13:57, Karsten Hilbert wrote:
>> Am Sun, Jan 17, 2021 at 02:20:24AM -0800 schrieb omid mohammadi:
>> 
>>> When I open the sentinel-2 image in Python, I get the following error:
>>>
>>> MemoryError: Unable to allocate 115. MiB for an array with shape
>>> (5490, 5490) and data type float32
>>>
>>> How can I fix it?
>> 
>> You can install more RAM.
>> 
> Or maybe the OP is running 32-bit Python but the code needs >2GB. If
> that's the case then using 64-bit Python might fix it, assuming that
> it's a 64-bit machine.

Or there may be an OS limitation on the size of the address space. I 
would check the OS log first, then do "ulimit -a". If there are sar or
vmstat on the system, I would definitely use them.
Running out of memory is an OS error and should be checked on the OS 
level.



-- 
Mladen Gogala
Database Consultant
http://mgogala.byethost5.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Issues with running python in Command prompt

[Mladen Gogala via Python-list]

On Sat, 16 Jan 2021 19:00:06 +0330, mohsen shooshtari wrote:

> hello,
> Thanks in advance for your consideration. I install python3.8 and then
> install Pycharm but when I call python in Command prompt, followed by (
> 'python'
> is not recognized as an internal or external command, operable program
> or batch file.
> 
> what should I do to fix this problem?

Make sure that OS recognizes it as a command. That usually means putting 
the directory where your Python resides into the path. I generally advise
using Cygwin and installing the Cygwin version of Python. Your OS will 
look like a POSIX compatible system, and you will be able to use Unix/
Linux tools like bash, less. vi, awk, grep and alike. You will also be 
able to use "/" as a directory separator which is really helpful when it 
comes to regular expressions.
Another option is to install Ubuntu on top of your Windows 10. I am no 
fan of Ubuntu but it's still much better than Windows. All scripting 
languages (PHP, Perl, Python, Go and JavaScript to mention only the most 
popular ones) are all written with Linux/Unix in mind. There are Windows 
ports but using the Linux or Cygwin version is typically much easier and 
more natural.

-- 
Mladen Gogala
Database Consultant
https://dbwhisperer.wordpress.com
-- 
https://mail.python.org/mailman/listinfo/python-list