[issue43221] German Text Conversion Using Upper() and Lower()

[Steven D'Aprano]

Steven D'Aprano  added the comment:

>>> '\N{LATIN SMALL LETTER SHARP S}'
'ß'
>>> '\N{LATIN CAPITAL LETTER SHARP S}'
'ẞ'

The history of ß is complicated and differs in the Germany speaking countries 
of Austria, Switzerland and Germany, but the short version is that the 
uppercase version only became *officially* recognised by Germany in the 21st 
century, although it was unofficially in use back in the first half of the 20th 
century.

As far as I can tell, official German spelling rules still have uppercase of ß 
being SS, although that may be changing.

In any case, regardless of what the German, Austrian or Swiss German speakers 
do, Python will follow the Unicode rules, and that still has ß map to SS by 
default.

Any change in behaviour would have to be limited to Python 3.10 as 3.9 is in 
feature-freeze.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue43221] German Text Conversion Using Upper() and Lower()

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I guess this was discussed a few times in different issues. See also 
https://bugs.python.org/issue34928

--
nosy: +xtreak

___
Python tracker 

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

[issue43221] German Text Conversion Using Upper() and Lower()

[Eryk Sun]

Eryk Sun  added the comment:

Python uses standard Unicode character properties, as defined by the Unicode 
Consortium. This issue is discussed in their FAQ [1]: 

Q: Why does ß (U+00DF LATIN SMALL LETTER SHARP S) not uppercase to 
   U+1E9E LATIN CAPITAL LETTER SHARP S by default?

A: In standard German orthography, the sharp s ("ß") used to be 
   exclusively uppercased to a sequence of two capital S characters. 
   This longstanding practice is reflected in the default case 
   mappings in Unicode. A capital form of ß is sometimes preferred
   for typographic reasons or to avoid ambiguity, such as in
   uppercase names as found in passports. It is encoded in the
   Unicode Standard as U+1E9E. While this character is not widely
   used, [it] is now recognized in the official orthography as an 
   optional uppercase form of ß in addition to "SS".  Because it is
   only an optional alternative, the original mapping to "SS" is
   retained in the Unicode character properties. 

---
[1] http://unicode.org/faq/casemap_charprop.html#11

--
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue43221] German Text Conversion Using Upper() and Lower()

[Max Parry]

New submission from Max Parry :

The German alphabet has four extra characters (ä, ö, ü and ß) when compared to 
the UK/USA alphabet.  Until 2017 the character ß was normally only lower case.  
Upper case ß was represented by SS.  In 2017 upper case ß was introduced, 
although SS is still often/usually used instead.  It is important to note that, 
as far as I can see, upper case ß and lower case ß are identical.

The upper() method converts upper or lower case ß to SS.  N.B. ä, ö and ü are 
handled correctly.  Lower() seems to work correctly.

Please note that German is my second language and everything I say about the 
language, its history and its use might not be reliable.  Happy to be corrected.

--
components: Windows
messages: 386938
nosy: Strongbow, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: German Text Conversion Using Upper() and Lower()
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue43152] warning: unused variable 'code'

[Dong-hee Na]

Dong-hee Na  added the comment:

Now this issue is solved
Thank you Victor as the reviewer ;)

--
nosy: +vstinner
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue43152] warning: unused variable 'code'

[Dong-hee Na]

Dong-hee Na  added the comment:


New changeset 3cf0833f42ebde24f6435b838785ca4f946b988f by Dong-hee Na in branch 
'master':
bpo-43152: Update assert statement to remove unused warning (GH-24473)
https://github.com/python/cpython/commit/3cf0833f42ebde24f6435b838785ca4f946b988f


--

___
Python tracker 

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

[issue43219] shutil.copy raises IsADirectoryError when the directory does not actually exist

[Eryk Sun]

Eryk Sun  added the comment:

> IsADirectoryError: [Errno 21] Is a directory: 'not_a_dir/'

The trailing slash forces the OS to handle "not_a_dir" as a directory [1]. 

A pathname that contains at least one non-  character and that 
ends with one or more trailing  characters shall not be resolved
successfully unless the last pathname component before the trailing 
 characters names an existing directory or a directory entry 
that is to be created for a directory immediately after the pathname is
resolved. 

Mode "w" corresponds to low-level POSIX open() flags O_CREAT | O_TRUNC | 
O_WRONLY. If write access is requested for a directory, the open() system call 
must fail with EISDIR [2].

[EISDIR]
The named file is a directory and oflag includes O_WRONLY or O_RDWR,
or includes O_CREAT without O_DIRECTORY.

In most cases, opening a directory with O_CREAT also fails with E_ISDIR. POSIX 
does permit an implementation to create a directory with O_CREAT | O_DIRECTORY. 
In Linux, however, O_CREAT always creates a regular file, regardless of 
O_DIRECTORY, so open(pathname, O_CREAT | flags) always fails with EISDIR when 
pathname is an existing directory or names a directory by way of a trailing 
slash.

---
[1] 
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

--
nosy: +eryksun

___
Python tracker 

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

[issue43220] Explicit default required arguments with add_mutually_exclusive_group are rejected

[Keith Smiley]

Change by Keith Smiley :


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

___
Python tracker 

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

[issue43220] Explicit default required arguments with add_mutually_exclusive_group are rejected

[Keith Smiley]

New submission from Keith Smiley :

With this code:

```
import argparse

parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group(required=True)
group.add_argument("--foo", default="1")
group.add_argument("--bar")
args = parser.parse_args()
print(args)
```

When you explicitly pass `--foo 1`, it is treated as if no argument was passed:

```
% python3 /tmp/bug.py --foo 1
usage: bug.py [-h] (--foo FOO | --bar BAR)
bug.py: error: one of the arguments --foo --bar is required
```

I can't tell if this behavior is intentional, but it was surprising to me. It 
also seems to be somewhat based on the length of the default string. For 
example on my macOS machine if I change the default to `longerstring` it does 
not have this issue.

--
components: Library (Lib)
messages: 386934
nosy: keith
priority: normal
severity: normal
status: open
title: Explicit default required arguments with add_mutually_exclusive_group 
are rejected
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue43219] shutil.copy raises IsADirectoryError when the directory does not actually exist

[Jeremy Pinto]

Jeremy Pinto  added the comment:

In fact, the issue seems to be coming from open() itself when opening a 
non-existent directory in write mode:

[nav] In [1]: import os
 ...: nonexixstent_dir = 'not_a_dir/'
 ...: assert not os.path.exists(nonexixstent_dir)
 ...: with open(nonexixstent_dir, 'wb') as fdst:
 ...: pass
---
IsADirectoryError Traceback (most recent call last)
 in 
  2 dir_path = 'not_a_dir/'
  3 assert not os.path.exists(nonexixstent_dir)
> 4 with open(nonexixstent_dir, 'wb') as fdst:
  5 pass

IsADirectoryError: [Errno 21] Is a directory: 'not_a_dir/'

--

___
Python tracker 

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

Re: Sketch

[Igor Korot]

Hi,



On Sat, Feb 13, 2021, 9:12 PM Mr Flibble 
wrote:

> On 14/02/2021 05:04, Mark Lawrence wrote:
> > On Sunday, February 14, 2021 at 5:01:46 AM UTC, Mr Flibble wrote:
> >> CPython *is* the dead parrot.
> >>
> >> It's time for Python to evolve out of the primordial soup.
> >>
> >> /Flibble
>

Is there a proof?
Because I could say that JAVA sucks, but without proof it will be just
words...

Thank you.

>>
> >> --
> >> 
> >
> > Says the bloke(?) who doesn't use mailing lists but does get here
> https://mail.python.org/pipermail/python-list/2021-February/900797.html
>
> I am using Usenet, dear. Apparently posts to comp.lang.python are copied
> to the mailing list which you worship like a god.
>
> /Flibble
>
> --
> 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43219] shutil.copy raises IsADirectoryError when the directory does not actually exist

[Jeremy Pinto]

New submission from Jeremy Pinto :

Issue: If you try to copy a file to a directory that doesn't exist using 
shutil.copy, a IsADirectory error is raised saying the directory exists. 

This issue is actually caused when `open(not_a_dir, 'wb') is called on a 
non-existing dir.

Expected behaviour: Should instead raise NotADirectoryError
-

Steps to reproduce:

[nav] In [1]: import os
 ...: from pathlib import Path
 ...: from shutil import copy
 ...:
 ...: tmp_file = '/tmp/some_file.txt'
 ...: Path(tmp_file).touch()
 ...: nonexistent_dir = 'not_a_dir/'
 ...: assert not os.path.exists(nonexistent_dir)
 ...: copy(tmp_file, nonexistent_dir)
---
IsADirectoryError Traceback (most recent call last)
 in 
  7 nonexistent_dir = 'not_a_dir/'
  8 assert not os.path.exists(nonexistent_dir)
> 9 copy(tmp_file, nonexistent_dir)

~/miniconda3/lib/python3.7/shutil.py in copy(src, dst, follow_symlinks)
243 if os.path.isdir(dst):
244 dst = os.path.join(dst, os.path.basename(src))
--> 245 copyfile(src, dst, follow_symlinks=follow_symlinks)
246 copymode(src, dst, follow_symlinks=follow_symlinks)
247 return dst

~/miniconda3/lib/python3.7/shutil.py in copyfile(src, dst, follow_symlinks)
119 else:
120 with open(src, 'rb') as fsrc:
--> 121 with open(dst, 'wb') as fdst:
122 copyfileobj(fsrc, fdst)
123 return dst

IsADirectoryError: [Errno 21] Is a directory: 'not_a_dir/'

--
messages: 386932
nosy: jerpint
priority: normal
severity: normal
status: open
title: shutil.copy raises IsADirectoryError when the directory does not 
actually exist
versions: Python 3.7

___
Python tracker 

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

Re: Sketch

[Mr Flibble]

On 14/02/2021 05:04, Mark Lawrence wrote:

On Sunday, February 14, 2021 at 5:01:46 AM UTC, Mr Flibble wrote:

CPython *is* the dead parrot.

It's time for Python to evolve out of the primordial soup.

/Flibble

--



Says the bloke(?) who doesn't use mailing lists but does get here 
https://mail.python.org/pipermail/python-list/2021-February/900797.html


I am using Usenet, dear. Apparently posts to comp.lang.python are copied to the 
mailing list which you worship like a god.

/Flibble

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

Sketch

[Mr Flibble]

CPython *is* the dead parrot.

It's time for Python to evolve out of the primordial soup.

/Flibble

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

Re: New Python implementation

[Mr Flibble]

On 14/02/2021 03:26, Grant Edwards wrote:

On 2021-02-14, Ned Batchelder  wrote:

On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote:


At the absolute least, show that you have something that can run Python code.


The OP has been making these claims on IRC for a (at least two
years). He has never cared to substantiate them, or even participate
in a civil and detailed discussion.  He is either 1) smarter than
all of us, or 2) woefully under-informed, or 3) trolling.


He posts using the name of a hand-puppet. I think that provides a bit
of a clue as to which of the 3 is most likely. And it's not even a
_real_ hand-puppet: it's a computer-generated hologram of a hand
hand-puppet.


lulz. If I am a troll then Elon Musk is also a troll.

/Flibble

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

Re: New Python implementation

[Mr Flibble]

On 14/02/2021 00:52, Alan Gauld wrote:

On 14/02/2021 00:07, Mr Flibble wrote:

On 13/02/2021 18:11, Alan Gauld wrote:



You are going to create a Python compiler that will take existing
Python code and output a byte code file.


No neos is not a Python compiler: it is a *universal* compiler that
can compile any programming language describable by a schema file


Yes, I understand that, but from the perspective of this list
what you are doing is providing a tool (a combination of neos
and a schema) that will take in Python source code and spit out
neos byte code. So, to all intents and purposes it is a Python
compiler (albeit capable of more when needed).


If that's correct, then how do you propose to deal with
regular Python byte code? And what would the Python disassembler
produce - Python assembler instructions or neos?


The neos Python implementation will not be dealing
with Python byte code in any form whatsoever.


Ok  but what do you do with the disassembler module?
Will it read neos byte code instead of the Python codes?
Also what about tools that work at the byte code level,
I assume they will not work with neos either?
That might include the profiler and debugger for example?


neos will include a language agnostic disassembler and debugger.



Also what would happen with the interactive prompt (>>>)
I'm assuming you'd expect users to continue using the CPython
interpreter and only compile the source after it was working
there? Like turning on the optimiser in a traditional
compiled language like C.


neos will include support for interactive sessions; no reason to use CPython at 
all.

/Flibble

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

[issue43218] after venv activation "which python3" and sys.path both give base installation instead of venv

[Neel Gore]

New submission from Neel Gore :

Fresh python 3.9.1 installation on macOS, shell is zsh

activated a venv with "python3 -m venv .venv"
activated with "source .venv/bin./activate"

"which python3" and "which pip3" both show my base installation

--
components: macOS
files: Screen Shot 2021-02-13 at 8.31.20 PM.png
messages: 386931
nosy: ned.deily, neeltennis, ronaldoussoren
priority: normal
severity: normal
status: open
title: after venv activation "which python3" and sys.path both give base 
installation instead of venv
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49807/Screen Shot 2021-02-13 at 8.31.20 
PM.png

___
Python tracker 

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

Re: New Python implementation

[Alan Gauld via Python-list]

On 14/02/2021 00:07, Mr Flibble wrote:
> On 13/02/2021 18:11, Alan Gauld wrote:

>> You are going to create a Python compiler that will take existing
>> Python code and output a byte code file.
> 
> No neos is not a Python compiler: it is a *universal* compiler that 
> can compile any programming language describable by a schema file 

Yes, I understand that, but from the perspective of this list
what you are doing is providing a tool (a combination of neos
and a schema) that will take in Python source code and spit out
neos byte code. So, to all intents and purposes it is a Python
compiler (albeit capable of more when needed).

>> If that's correct, then how do you propose to deal with
>> regular Python byte code? And what would the Python disassembler
>> produce - Python assembler instructions or neos?
> 
> The neos Python implementation will not be dealing 
> with Python byte code in any form whatsoever.

Ok  but what do you do with the disassembler module?
Will it read neos byte code instead of the Python codes?
Also what about tools that work at the byte code level,
I assume they will not work with neos either?
That might include the profiler and debugger for example?

Also what would happen with the interactive prompt (>>>)
I'm assuming you'd expect users to continue using the CPython
interpreter and only compile the source after it was working
there? Like turning on the optimiser in a traditional
compiled language like C.

-- 
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

Re: New Python implementation

[Grant Edwards]

On 2021-02-14, Ned Batchelder  wrote:
> On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote:
>
>> At the absolute least, show that you have something that can run Python 
>> code. 
>
> The OP has been making these claims on IRC for a (at least two
> years). He has never cared to substantiate them, or even participate
> in a civil and detailed discussion.  He is either 1) smarter than
> all of us, or 2) woefully under-informed, or 3) trolling.

He posts using the name of a hand-puppet. I think that provides a bit
of a clue as to which of the 3 is most likely. And it's not even a
_real_ hand-puppet: it's a computer-generated hologram of a hand
hand-puppet.





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

Re: New Python implementation

[Mr Flibble]

On 14/02/2021 02:54, Mark Lawrence wrote:

On Sunday, February 14, 2021 at 2:18:03 AM UTC, Mr Flibble wrote:

On 14/02/2021 00:51, Ned Batchelder wrote:
  

The OP has been making these claims on IRC for a while (at least two years). He 
has never cared to substantiate them, or even participate in a civil and 
detailed discussion. He is either 1) smarter than all of us, or 2) woefully 
under-informed, or 3) trolling. Our best course is to ignore him until he has 
code we can try.

I am sure you are most annoyed that you can't ban me from Usenet, dear, like 
you banned me from IRC. You need to grow the fuck up.


I take it that you didn't write "How to win friends and influence people"?  I 
don't suppose that the moderators will actually wake up and remove you from the mailing 
lists asap.


I see you are just as prickly as Ned, Mark. May I suggest that you too grow a 
pair? I am not on the mailing list BTW; e-mail lists are an outmoded concept 
much like CPython.

/Flibble

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

Re: New Python implementation

[Mr Flibble]

On 14/02/2021 03:35, Paul Rubin wrote:

Mr Flibble  writes:

I am creating neos as I need a performant scripting engine for my
other major project "neoGFX" and I want to be able to support multiple
popular scripting languages including Python.


Is something wrong with Guile for that purpose?  If yes, maybe you are
setting yourself up for the exact same obstacles ;-).


NIH.

/Flibble

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

Re: New Python implementation

[Mr Flibble]

On 14/02/2021 00:51, Ned Batchelder wrote:

On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote:

On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble
 wrote:


On 13/02/2021 23:30, Igor Korot wrote:

Hi,
But most importantly - what is the reason for this ?
I mean - what problems the actual python compiler produce?

Thank you.


I am creating neos as I need a performant scripting engine for my other major project 
"neoGFX" and I want to be able to support multiple popular scripting languages 
including Python.


Until you have actually produced a (mostly) compatible Python
implementation, can you please stop making these repeated and baseless
jabs at CPython's performance? You keep stating or hinting that
CPython is somehow unnecessarily slow, but unless you have some code
to back your claims, this is nothing but mudslinging.

CPython is not as slow as you might think. And PyPy is highly
efficient at what it does well. Show us that you can do better than
these before you call them slow.

At the absolute least, show that you have something that can run Python code.

ChrisA


The OP has been making these claims on IRC for a while (at least two years). He 
has never cared to substantiate them, or even participate in a civil and 
detailed discussion.  He is either 1) smarter than all of us, or 2) woefully 
under-informed, or 3) trolling.  Our best course is to ignore him until he has 
code we can try.


I am sure you are most annoyed that you can't ban me from Usenet, dear, like 
you banned me from IRC. You need to grow the fuck up.

Your use of the words "all of us" is disingenuous, try "me" instead.  "All of 
us" includes people as smart as me but can't be arsed fixing the Python space because they can just 
about live with the status quo.

/Flibble

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

Re: New Python implementation

[Mr Flibble]

On 14/02/2021 00:19, Chris Angelico wrote:

On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble
 wrote:


On 13/02/2021 23:30, Igor Korot wrote:

Hi,
But most importantly - what is the reason for this ?
I mean - what problems the actual python compiler produce?

Thank you.


I am creating neos as I need a performant scripting engine for my other major project 
"neoGFX" and I want to be able to support multiple popular scripting languages 
including Python.



Until you have actually produced a (mostly) compatible Python
implementation, can you please stop making these repeated and baseless
jabs at CPython's performance? You keep stating or hinting that
CPython is somehow unnecessarily slow, but unless you have some code
to back your claims, this is nothing but mudslinging.

CPython is not as slow as you might think. And PyPy is highly
efficient at what it does well. Show us that you can do better than
these before you call them slow.

At the absolute least, show that you have something that can run Python code.


It isn't just me that is saying CPython is egregiously slow: it is at the 
bottom of the list as far as performance is concerned. Python is undoubtedly 
the biggest contributor to climate change of all the programming languages in 
mainstream use today.

See: 
https://thenewstack.io/which-programming-languages-use-the-least-electricity/

/Flibble

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

Re: PSYCOPG2

[Mladen Gogala via Python-list]

I don't have PSYCOPG2 on my system, but try doing the following from 
python:
[mgogala@umajor ~]$ python3
Python 3.9.1 (default, Jan 20 2021, 00:00:00) 
[GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>> dir(cx_Oracle)
['ATTR_PURITY_DEFAULT', 'ATTR_PURITY_NEW', 'ATTR_PURITY_SELF', 'ApiType', 
'BFILE', 'BINARY', 'BLOB', 'BOOLEAN', 'Binary', 'CLOB', 'CURSOR', 
'Connection', 'Cursor', 'DATETIME', 'DBSHUTDOWN_ABORT',

 'DBSHUTDOWN_FINAL', 'DBSHUTDOWN_IMMEDIATE', 'DBSHUTDOWN_TRANSACTIONAL', 
'DBSHUTDOWN_TRANSACTIONAL_LOCAL', 'DB_TYPE_BFILE', 
'DB_TYPE_BINARY_DOUBLE', 'DB_TYPE_BINARY_FLOAT', 
'DB_TYPE_BINARY_INTEGER', 'DB_TYPE_BLOB', 'DB_TYPE_BOOLEAN', 
'DB_TYPE_CHAR', 'DB_TYPE_CLOB', 'DB_TYPE_CURSOR', 'DB_TYPE_DATE', 
'DB_TYPE_INTERVAL_DS', 'DB_TYPE_INTERVAL_YM', 'DB_TYPE_JSON', 
'DB_TYPE_LONG', 'DB_TYPE_LONG_RAW', 'DB_TYPE_NCHAR', 'DB_TYPE_NCLOB', 
'DB_TYPE_NUMBER', 'DB_TYPE_NVARCHAR', 'DB_TYPE_OBJECT', 'DB_TYPE_RAW', 
'DB_TYPE_ROWID', 'DB_T
...

>>> conn=cx_Oracle.Connection("scott/tiger@ora19c")
>>> 
Please use PSYCOPG2 instead of cx_Oracle. After you do it 
from python3 interpreter do it from Idle:



On Sat, 13 Feb 2021 22:08:11 +, Tony Ogilvie wrote:

> Thank you
> 
> I have tried Sublime 3 and the same thing happens. I do not think I have
> another version of Python on my PC. I am trying to look through my files
> to find out.
> 
> Regards
> 
> Tony
> 
> 
> -Original Message-
> From: Mladen Gogala 
> Sent: 13 February 2021 05:35 To: python-list@python.org Subject: Re:
> PSYCOPG2
> 
> On Fri, 12 Feb 2021 18:29:48 +, Tony Ogilvie wrote:
> 
>> I am trying to write a program to open a PostgesSQL 13 database using
>> psycopg2. All seems to work if I write direct to Python but if I write
>> the script into IDLE it does not work with the IDLE Shell 3.9.1
>> reporting an error of no attribute 'connect'.
>> 
>> 
>> 
>> I have tried many options to try and get this to work.
>> 
>> 
>> 
>> Regards
>> 
>> 
>> 
>> Tony
> 
> It looks like your idle is not using the same interpreter that you are
> using when writing direct code. Anyway, my advice would be to ditch Idle
> and use VSCode. It's fabulous.





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

Re: New Python implementation

[Ned Batchelder]

On Saturday, February 13, 2021 at 7:19:58 PM UTC-5, Chris Angelico wrote:
> On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble 
>  wrote: 
> > 
> > On 13/02/2021 23:30, Igor Korot wrote: 
> > > Hi, 
> > > But most importantly - what is the reason for this ? 
> > > I mean - what problems the actual python compiler produce? 
> > > 
> > > Thank you. 
> > 
> > I am creating neos as I need a performant scripting engine for my other 
> > major project "neoGFX" and I want to be able to support multiple popular 
> > scripting languages including Python. 
> >
> Until you have actually produced a (mostly) compatible Python 
> implementation, can you please stop making these repeated and baseless 
> jabs at CPython's performance? You keep stating or hinting that 
> CPython is somehow unnecessarily slow, but unless you have some code 
> to back your claims, this is nothing but mudslinging. 
> 
> CPython is not as slow as you might think. And PyPy is highly 
> efficient at what it does well. Show us that you can do better than 
> these before you call them slow. 
> 
> At the absolute least, show that you have something that can run Python code. 
> 
> ChrisA

The OP has been making these claims on IRC for a while (at least two years). He 
has never cared to substantiate them, or even participate in a civil and 
detailed discussion.  He is either 1) smarter than all of us, or 2) woefully 
under-informed, or 3) trolling.  Our best course is to ignore him until he has 
code we can try.

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

RE: New Python implementation

[Avi Gross via Python-list]

It is likely that people would understand better if spoken to properly so I 
have been listening and hopefully gaining a picture that I can share, and be 
corrected helpfully when wrong.

My personal guess is that the project at hand is to do something very vaguely 
like what was done to the CURSES functionality ages ago in prehistory where 
lots of different terminals (and terminal emulators) used an assortment of 
control and escape sequences to make a text-based terminal do things like 
delete to the end of a line. The idea was to extract out all kinds of 
functionality used by pretty much all the terminals and save the info for say 
the hp2621 terminal either in a file with that name, or as entries in a file 
specifying many terminals or even in your environment. Then you made sure you 
had some variable like TERM set to hp2621 or whatever. If later you logged in 
on another kind of terminal, it would adjust dynamically for that without 
changing your program.

When a program like vi(m) or emacs ran, it used the curses library which would 
dynamically reconfigure based on the  terminal used and try to figure out the 
cheapest way  (in terms of characters and I/O usually) to send extra escape 
sequences to update your screen as changes were made. Sometimes it would clear 
the screen and re-enter the new stuff and sometimes delete three lines then put 
in the replacement and so on.

End of example. There are other examples like a format for documents that might 
take one of many ones like Word and make a common storage format that can 
easily be printed on any device that supports the features. The important 
aspect for me, is abstraction. 

My impression is the proposed project would abstract out the details of what 
any language can do and then examine one language after another (such as Ada or 
Python) and create some kind of description that can be stored, such as in a 
file. I have no idea what that might look like. I assume it would include what 
keywords there are or what variable names might look like or if some construct 
has an ending like "FI" or "endif" or "}"  and it is only once this is 
completed, that the next phase can be used.

It sounds like they would have what he considers a universal compiler that 
determines what language (perhaps even version) a file or group of files are 
using and then loads in info that metamorphizes it into an effective compiler 
for that language. It may not be that simple and I have no idea how it does 
that or how it outputs the result but it sounds like they have yet another 
language we might loosely compare to the byte stream used by JAVA and SCALA and 
some others that is half-digested and can be run by the JVM, or the Python 
version of something along those lines. 

In any case, I get the impression that this output will then look about the 
same no matter what language it came from. It will not require specific 
run-time environments but one overarching runtime that can run anything, again, 
using whatever abstraction or rules they come up with. And, in some cases, you 
may choose to go a step further and take this portable file format and compile 
it further down to an executable that runs on a specific machine and so on. I 
shudder at how well it will output error messages!

Assuming this is feasible and well done, it might open quite a few doors in 
terms of designing both mini-languages and variants on existing ones and brand 
new ones with new ideas. You would have to find a way to describe your language 
as described above and as long as it is consistent in some ways, no need to 
ever build your own interpreter or compiler. It might be a bit like designing a 
new terminal (or just emulator) that has features you want. Mind you, some of 
the new features might require changes in the "Neo" something/data  before it 
can be handled, but once added, any other language, within reason, might be 
able to add a similar feature and it should work.

I hope I got this at least partially right and it is more informative that 
repeatedly telling people things like "Nope" as if this is a quiz and not an 
informative  discussion.

-Original Message-
From: Python-list  On 
Behalf Of Mr Flibble
Sent: Saturday, February 13, 2021 7:07 PM
To: python-list@python.org
Subject: Re: New Python implementation

On 13/02/2021 18:11, Alan Gauld wrote:
> On 13/02/2021 16:09, Mr Flibble wrote:
>> On 13/02/2021 00:01, Alan Gauld wrote:
>>> I'm assuming it's a new executable interpreter that can run any 
>>> valid python code. Is that correct?
>>
>> It is a universal *compiler* so it compiles the python code to byte 
>> code and then optionally to machine code via a JIT which is then executed.
> 
> OK, sorry for being dense, but just to be absolutely clear.
> 
> You are going to create a Python compiler that will take existing 
> Python code and output a byte code file. (I assume the byte code is 
> not standard Python byte code?) And I assume the execution 

[issue43217] tkinter style map return value in alt theme

[misianne]

New submission from misianne :

The return value for ttk.style().map('Treeview') is wrong for the 'background' 
value in the 'alt' theme: tuple are missing.

Tcl alt Treeview map:

-foreground {disabled #a3a3a3 {!disabled !selected} black selected #ff} 
-background {disabled #d9d9d9 {!disabled !selected} #ff selected #4a6984}


tkinter alt Treeview map:

{
'foreground': [('disabled', '#a3a3a3'), ('!disabled', '!selected', 'black'), 
('selected', '#ff')], 
'background': ['disabled', '#d9d9d9', '!disabled !selected', '#ff', 
'selected', '#4a6984']
}

It should be:

'background': [('disabled', '#d9d9d9'), ('!disabled !selected', '#ff'), 
('selected', '#4a6984')]

--
components: Tkinter
messages: 386930
nosy: misianne
priority: normal
severity: normal
status: open
title: tkinter style map return value in alt theme
type: behavior
versions: Python 3.8

___
Python tracker 

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

Re: New Python implementation

[Chris Angelico]

On Sun, Feb 14, 2021 at 11:14 AM Mr Flibble
 wrote:
>
> On 13/02/2021 23:30, Igor Korot wrote:
> > Hi,
> > But most importantly - what is the reason for this ?
> > I mean - what problems the actual python compiler produce?
> >
> > Thank you.
>
> I am creating neos as I need a performant scripting engine for my other major 
> project "neoGFX" and I want to be able to support multiple popular scripting 
> languages including Python.
>

Until you have actually produced a (mostly) compatible Python
implementation, can you please stop making these repeated and baseless
jabs at CPython's performance? You keep stating or hinting that
CPython is somehow unnecessarily slow, but unless you have some code
to back your claims, this is nothing but mudslinging.

CPython is not as slow as you might think. And PyPy is highly
efficient at what it does well. Show us that you can do better than
these before you call them slow.

At the absolute least, show that you have something that can run Python code.

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

Re: New Python implementation

[Mr Flibble]

On 13/02/2021 23:30, Igor Korot wrote:

Hi,
But most importantly - what is the reason for this ?
I mean - what problems the actual python compiler produce?

Thank you.


I am creating neos as I need a performant scripting engine for my other major project 
"neoGFX" and I want to be able to support multiple popular scripting languages 
including Python.

/Flibble

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

Re: New Python implementation

[Mr Flibble]

On 13/02/2021 18:11, Alan Gauld wrote:

On 13/02/2021 16:09, Mr Flibble wrote:

On 13/02/2021 00:01, Alan Gauld wrote:

I'm assuming it's a new executable interpreter that can run any
valid python code. Is that correct?


It is a universal *compiler* so it compiles the python code to byte code
and then optionally to machine code via a JIT which is then executed.


OK, sorry for being dense, but just to be absolutely clear.

You are going to create a Python compiler that will take existing
Python code and output a byte code file. (I assume the byte code
is not standard Python byte code?) And I assume the execution
environment for the bytecode is part of your neos system?


No neos is not a Python compiler: it is a *universal* compiler that can compile 
any programming language describable by a schema file and any language-specific 
semantic concepts.  The byte code will be proprietary, yes, and will be 
executed by neos and/or JITed.



If that's correct, then how do you propose to deal with
regular Python byte code? And what would the Python disassembler
produce - Python assembler instructions or neos?


The neos Python implementation will not be dealing with Python byte code in any 
form whatsoever.

/Flibble

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

Re: New Python implementation

[Igor Korot]

Hi,
But most importantly - what is the reason for this ?
I mean - what problems the actual python compiler produce?

Thank you.


On Sat, Feb 13, 2021, 3:26 PM Alan Gauld via Python-list <
python-list@python.org> wrote:

> On 13/02/2021 16:09, Mr Flibble wrote:
> > On 13/02/2021 00:01, Alan Gauld wrote:
> >> I'm assuming it's a new executable interpreter that can run any
> >> valid python code. Is that correct?
> >
> > It is a universal *compiler* so it compiles the python code to byte code
> > and then optionally to machine code via a JIT which is then executed.
>
> OK, sorry for being dense, but just to be absolutely clear.
>
> You are going to create a Python compiler that will take existing
> Python code and output a byte code file. (I assume the byte code
> is not standard Python byte code?) And I assume the execution
> environment for the bytecode is part of your neos system?
>
> If that's correct, then how do you propose to deal with
> regular Python byte code? And what would the Python disassembler
> produce - Python assembler instructions or neos?
>
> --
> 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
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New Python implementation

[Alan Gauld via Python-list]

On 13/02/2021 16:09, Mr Flibble wrote:
> On 13/02/2021 00:01, Alan Gauld wrote:
>> I'm assuming it's a new executable interpreter that can run any
>> valid python code. Is that correct?
> 
> It is a universal *compiler* so it compiles the python code to byte code 
> and then optionally to machine code via a JIT which is then executed.

OK, sorry for being dense, but just to be absolutely clear.

You are going to create a Python compiler that will take existing
Python code and output a byte code file. (I assume the byte code
is not standard Python byte code?) And I assume the execution
environment for the bytecode is part of your neos system?

If that's correct, then how do you propose to deal with
regular Python byte code? And what would the Python disassembler
produce - Python assembler instructions or neos?

-- 
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

PyCA cryptography 3.4.5 released

[Paul Kehrer]

PyCA cryptography 3.4.5 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog.html#v3-4-5):
* Various improvements to type hints.
* Lower the minimum supported Rust version (MSRV) to >=1.41.0. This
change improves compatibility with system-provided Rust on several
Linux distributions.
* cryptography will be switching to a new versioning scheme with its
next feature release. More information is available in our API
stability documentation.

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

RE: PSYCOPG2

[Tony Ogilvie]

Thank you

I have tried Sublime 3 and the same thing happens. I do not think I have
another version of Python on my PC. I am trying to look through my files to
find out.

Regards

Tony


-Original Message-
From: Mladen Gogala  
Sent: 13 February 2021 05:35
To: python-list@python.org
Subject: Re: PSYCOPG2

On Fri, 12 Feb 2021 18:29:48 +, Tony Ogilvie wrote:

> I am trying to write a program to open a PostgesSQL 13 database using 
> psycopg2. All seems to work if I write direct to Python but if I write 
> the script into IDLE it does not work with the IDLE Shell 3.9.1 
> reporting an error of no attribute 'connect'.
> 
> 
>  
> I have tried many options to try and get this to work.
> 
> 
>  
> Regards
> 
> 
>  
> Tony

It looks like your idle is not using the same interpreter that you are using
when writing direct code. Anyway, my advice would be to ditch Idle and use
VSCode. It's fabulous.



--
Mladen Gogala
Database Consultant
https://dbwhisperer.wordpress.com


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

[issue42819] readline 8.1 bracketed paste

[Miro Hrončok]

Miro Hrončok  added the comment:

This also affects Fedora 34+

--
nosy: +hroncok, petr.viktorin, vstinner

___
Python tracker 

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

Re: PSYCOPG2

[dn via Python-list]

On 13/02/2021 18.34, Mladen Gogala via Python-list wrote:
> On Fri, 12 Feb 2021 18:29:48 +, Tony Ogilvie wrote:
> 
>> I am trying to write a program to open a PostgesSQL 13 database using
>> psycopg2. All seems to work if I write direct to Python but if I write
>> the script into IDLE it does not work with the IDLE Shell 3.9.1
>> reporting an error of no attribute 'connect'.
>>
>> I have tried many options to try and get this to work.

Please copy-paste the code of at least one of these "options", together
with the full error-listing.

Before using the connect function, the module must be import-ed. Has
this been done?

If so, an error with connect() probably indicates a problem with the
function call, eg locating the database.

- as said, really difficult without seeing any code and the err.msgs
generated!


> It looks like your idle is not using the same interpreter that you are 
> using when writing direct code. Anyway, my advice would be to ditch Idle 
> and use VSCode. It's fabulous.


Would it?

Surely if the issue is 'connecting bits together', regardless one still
has to learn the tool and how it works/expects things to be organised?

So, rather than helping the OP with a Postgres/Python/psycopg2 linkage
problem, hasn't (s)he now been presented with an extra learning load?

Regardless, rather than recommending that people send their
'telemetry/tracking data' to MSFT, why not suggest VSCodium
(https://vscodium.com/) - the same open-source IDE, before any such
'extras' are added.


Disclaimer: I do not use or publish Idle, VS-Code, or VSCodium, and have
nothing to gain/lose by MSFT collecting data about what you are doing
with the help of 'their' product.
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43146] 3.10a5 regression: AttributeError: 'NoneType' object has no attribute '__suppress_context__' in traceback.py

[Irit Katriel]

Irit Katriel  added the comment:

> I wonder what the rationale was.  It isn't because these functions never 
> raise.

I think it's because sys.exc_info() can return None, None, None when there is 
no exceptions.

--

___
Python tracker 

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

RE: mutating a deque whilst iterating over it

[Avi Gross via Python-list]

I agree both with the idea that it is not good to mutate things during
iteration and that some things we want to do may seemingly require
effectively something like a mutation.

I want to consider what data structure might capture a normal activity like
having a to-do-list for TODAY and another for further in the future. I might
sit down in the morning and look at my day and the list of activities I was
going to do. I might note new activities to add, some that are done or moot
and can be removed and some that should be done earlier or deferred to later
or even into the next day. This does not seem easy to do iteratively.
Weirder, if I throw each item at the end, I end up with the same items in
the same order.

So creating a data structure (such as an object like a deque but with more
specific functionality) might take some work. To begin, you might want an
iteration protocol that locks it till done. Not necessarily because of
mutation, though. Within the iteration you might have code asking for what I
might consider delayed actions. You can ask for the current item to be
deleted or moved to a data structure for the next day and it will not be
done now but some reference might be stored inside the object such as a
DELETE list and a MOVE list. You may also have lists with names like HIGH,
MEDIUM and LOW or priorities from 1 to N. I don't mean python lists, just
some kind of way of assigning some meaning to each item as you go. You may
even want a way to break a task into multiple parts or declare a dependency
between them such as one having to be done before the other.

When you are done iterating, presumably the data structure will then reorder
itself in a scenario where mutability is done harmlessly and a new list or
deque or whatever is reconstituted and you can unlock.

I do note that years ago I took a course in time management that ended up
spending way too much time doing this kind of task on paper multiple time a
day with lots of erasing or rewriting. The idea was to get more of the
important things done. These days, I am so interrupt-driven that such a
system is not useful albeit a nice automated way might be helpful as my day
constantly mutates to become unrecognizable.

There are project management tools along the lines I describe that try to
manage timelines and dependencies across multiple groups and measure
deliverables and note when something will cause delays in others and so on.
Obviously, beyond the scope but my point is they do not necessarily operate
in one pass over the list and are quite a bit more complex.

-Original Message-
From: Python-list  On
Behalf Of Dan Stromberg
Sent: Saturday, February 13, 2021 2:13 PM
To: duncan smith 
Cc: Python List 
Subject: Re: mutating a deque whilst iterating over it

On Sat, Feb 13, 2021 at 10:25 AM duncan smith 
wrote:

> On 12/02/2021 03:04, Terry Reedy wrote:
> > On 2/11/2021 3:22 PM, duncan smith wrote:
> >
> >>It seems that I can mutate a deque while iterating over it 
> >> if I assign to an index, but not if I append to it. Is this the 
> >> intended behaviour?
>
> What I was really wondering was whether the behaviour is as it is 
> because of the implementation or because it's how deques should 
> ideally behave. i.e. In my implementation do I stick strictly to the 
> same API, or allow it to differ? In some places I'm jumping through 
> hoops to stick to the API, and (when it comes to iteration) I'm 
> jumping through different hoops for different types of container (e.g. 
> lists versus deques). BTW, the reason I am implementing these at all 
> is that my containers are on-disk. Cheers.
>
> collections.deque appears to take the approach of  "allow everything 
> we
can based on our implementation, and trust the client not to overuse
features".

In fact, in Python, "over abstraction" is often seen as a bad thing, mostly
because it slows things down so much.

If you want something more abstracted, you might have a look at:
https://stromberg.dnsalias.org/~strombrg/linked-list/
https://pypi.org/project/linked_list_mod/

(Both URL's are about the same module)

Note that linked_list_mod is quite a bit slower than a collections.deque.
Deques use a clever-but-hidden trick to gain a lot of speed - it's really a
linked list of built in lists, which gives better locality of reference that
masks CPU caches very happy.  linked_list_mod goes for abstraction and
simplicity.
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: mutating a deque whilst iterating over it

[Dan Stromberg]

On Sat, Feb 13, 2021 at 10:25 AM duncan smith 
wrote:

> On 12/02/2021 03:04, Terry Reedy wrote:
> > On 2/11/2021 3:22 PM, duncan smith wrote:
> >
> >>It seems that I can mutate a deque while iterating over it if I
> >> assign to an index, but not if I append to it. Is this the intended
> >> behaviour?
>
> What I was really wondering was whether the behaviour is as it is
> because of the implementation or because it's how deques should ideally
> behave. i.e. In my implementation do I stick strictly to the same API,
> or allow it to differ? In some places I'm jumping through hoops to stick
> to the API, and (when it comes to iteration) I'm jumping through
> different hoops for different types of container (e.g. lists versus
> deques). BTW, the reason I am implementing these at all is that my
> containers are on-disk. Cheers.
>
> collections.deque appears to take the approach of  "allow everything we
can based on our implementation, and trust the client not to overuse
features".

In fact, in Python, "over abstraction" is often seen as a bad thing, mostly
because it slows things down so much.

If you want something more abstracted, you might have a look at:
https://stromberg.dnsalias.org/~strombrg/linked-list/
https://pypi.org/project/linked_list_mod/

(Both URL's are about the same module)

Note that linked_list_mod is quite a bit slower than a collections.deque.
Deques use a clever-but-hidden trick to gain a lot of speed - it's really a
linked list of built in lists, which gives better locality of reference
that masks CPU caches very happy.  linked_list_mod goes for abstraction and
simplicity.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PSYCOPG2

[Sibylle Koczian]

Am 13.02.2021 um 06:34 schrieb Mladen Gogala via Python-list:

On Fri, 12 Feb 2021 18:29:48 +, Tony Ogilvie wrote:


I am trying to write a program to open a PostgesSQL 13 database using
psycopg2. All seems to work if I write direct to Python but if I write
the script into IDLE it does not work with the IDLE Shell 3.9.1
reporting an error of no attribute 'connect'.

I have tried many options to try and get this to work.



It looks like your idle is not using the same interpreter that you are
using when writing direct code. Anyway, my advice would be to ditch Idle
and use VSCode. It's fabulous.



That may or may not circumvent the problem but it won't help in clearing 
up the cause.


Without any code and without the exact error message we can only guess. 
I'm translating "an error of no attribute 'connect'" into
"AttributeError: module 'psycopg2' has no attribute 'connect'". Right? 
If yes, that would mean a module with this name was imported, but it 
wasn't the right module. Did you perhaps give that same name to some 
Python script you wrote yourself? In that case the call to 'connect' 
would work if and only if you start your program from a directory that 
doesn't contain this script. But of course you should rename it so it 
doesn't clash with a module of the standard library.


I think problems with different interpreters would rather result in a 
ModuleNotFoundError, wouldn't they?


HTH
Sibylle



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

Re: mutating a deque whilst iterating over it

[duncan smith]

On 12/02/2021 03:04, Terry Reedy wrote:
> On 2/11/2021 3:22 PM, duncan smith wrote:
> 
>>    It seems that I can mutate a deque while iterating over it if I
>> assign to an index, but not if I append to it. Is this the intended
>> behaviour?
> 
> Does the deque doc say anything about mutation while iterating? (Knowing
> the author of deque, I would consider everything about it intentional
> without *good* reason to think otherwise.
> 
> from collections import deque
> d = deque(range(8))
> it = iter(d)
> next(it)
>> 0
> d[1] = 78
> 
> This does not change the structure of the deque, so next does not
> notice.  It could be considered not be a mutation.  It could be detected
> by changing deque.__setitem__, but why bother and slow down all
> __setitem__ calls.
> 
> next(it)
>> 78
> d.append(8)
> 
> This changes the structure, which can apparently mess-up iteration.
> 
> next(it)
>> Traceback (most recent call last):
>>    File "", line 1, in 
>>  next(it)
>> RuntimeError: deque mutated during iteration
>
> 
> 

What I was really wondering was whether the behaviour is as it is
because of the implementation or because it's how deques should ideally
behave. i.e. In my implementation do I stick strictly to the same API,
or allow it to differ? In some places I'm jumping through hoops to stick
to the API, and (when it comes to iteration) I'm jumping through
different hoops for different types of container (e.g. lists versus
deques). BTW, the reason I am implementing these at all is that my
containers are on-disk. Cheers.

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

Nikola v8.1.3 is out!

[Chris Warrick]

On behalf of the Nikola team, I am pleased to announce the immediate
availability of Nikola v8.1.3. This release has some minor fixes, and
a minor dependency change.

What is Nikola?
===

Nikola is a static site and blog generator, written in Python.
It can use Mako and Jinja2 templates, and input in many popular markup
formats, such as reStructuredText and Markdown — and can even turn
Jupyter Notebooks into blog posts! It also supports image galleries,
and is multilingual. Nikola is flexible, and page builds are extremely
fast, courtesy of doit (which is rebuilding only what has been changed).

Find out more at the website: https://getnikola.com/

Downloads
=

Install using `pip install Nikola`.

Changes
===

Features


* Provide the full `GLOBAL_CONTEXT` to the post list shortcode plugin
  (Issue #3481)
* Add `BasePlugin.register_auto_watched_folder()`
* Allow different `PANDOC_OPTIONS` values based on input extensions
  by specifying a dict of `{".extension": [options]}` (Issue #3492)
* Allow boolean/integer `pretty_url` post meta values in YAML/TOML
  (Issue #3503)

Bugfixes


* Fix an `UnboundLocalError` crash in `nikola deploy` (Issue
  #3479)

Other
-

* For `nikola github_deploy`, the `ghp-import` PyPI package is now
  recommended instead of `ghp-import2`. Both versions should work,
  but you can’t have both installed at the same time. (Issue #3499)


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

Re: New Python implementation

[Terry Reedy]

On 2/12/2021 4:42 PM, Mr Flibble wrote:

On 12/02/2021 02:45, Terry Reedy wrote:

On 2/11/2021 5:33 PM, Mr Flibble wrote:

On 11/02/2021 22:25, Dan Stromberg wrote:
On Thu, Feb 11, 2021 at 2:00 PM Mr Flibble 


wrote:


On 11/02/2021 21:13, Dan Stromberg wrote:
Does your project have a name yet?  I'd like to follow it through 
google

alerts or an announcement mailing list.


"neos" - https://neos.dev/ https://github.com/i42output/neos



Pypi already appears to have another project named neos:
https://pypi.org/project/neos/


neos isn't a Python package so that isn't a problem.


Since it obviously is a Python package, as in importable into a Python 
program, why do you deny it?


You are mistaken: it isn't a Python package and it isn't importable into 
a Python program.


https://pypi.org/project/neos/ shows
import neos.makers as makers
import neos.cls as cls

When you wrote 'neos' without qualification right after the neos package 
url, I though you were referring to the package, not your neos.  My 
mistake and your unclear writing.


--
Terry Jan Reedy


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

[issue43216] Removal of @asyncio.coroutine in Python 3.10

[Illia Volochii]

New submission from Illia Volochii :

It looks like @asyncio.coroutine was scheduled to be removed in Python 3.10.

Is it still relevant?

https://bugs.python.org/issue36921
https://docs.python.org/3.10/library/asyncio-task.html#asyncio.coroutine

--
components: asyncio
messages: 386927
nosy: asvetlov, illia-v, yselivanov
priority: normal
severity: normal
status: open
title: Removal of @asyncio.coroutine in Python 3.10
versions: Python 3.10

___
Python tracker 

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

Re: New Python implementation

[Mr Flibble]

On 13/02/2021 00:01, Alan Gauld wrote:

On 12/02/2021 21:46, Mr Flibble wrote:


The neos Python implementation will consist of a schema file
which describes the language plus any Python-specific semantic concepts


So the schema file is some kind of formal grammar definition of
the language?

And you "compile" this directly into machine code?
Is that the idea?

So when you say you have a universal compiler for any language
what you mean is that you can produce a compiler/interpreter
for any language from a language definition/schema. Is that it?

I'm still not sure I understand what exactly you are proposing
to do. What the final output looks like?

I'm assuming it's a new executable interpreter that can run any
valid python code. Is that correct?


It is a universal *compiler* so it compiles the python code to byte code and 
then optionally to machine code via a JIT which is then executed.

/Flibble

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

[issue43215] Document Happy Eyeballs arguments of asyncio.open_connection

[Illia Volochii]

Change by Illia Volochii :


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

___
Python tracker 

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

[issue43215] Document Happy Eyeballs arguments of asyncio.open_connection

[Illia Volochii]

New submission from Illia Volochii :

The problem is similar to https://bugs.python.org/issue39128.

It is not documented that asyncio.open_connection accepts happy_eyeballs_delay 
and interleave that are passed to loop.create_connection.

https://docs.python.org/3/library/asyncio-stream.html#asyncio.open_connection

--
assignee: docs@python
components: Documentation, asyncio
messages: 386926
nosy: asvetlov, docs@python, illia-v, yselivanov
priority: normal
severity: normal
status: open
title: Document Happy Eyeballs arguments of asyncio.open_connection
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 

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

[issue43205] Python Turtle Colour

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

If issue24990 is closed, this issue should be closed as well, as it is just a 
particular case of issue24990.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Foreign language support in turtle module

___
Python tracker 

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

[issue43213] Shortcut for checking if PurePath object contains str

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I guess that you need to use the parts attribute. Note that `'share' in 
str(path)` and `'share' in path.parts` are two very different things, even if 
they can give the same result in some cases.

When reply be email, please remove the quoted text. It makes reading difficult, 
especially for people with disabilities.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue42580] ctypes.util.find_library("libc") fails

[Alex Shpilkin]

Change by Alex Shpilkin :


--
nosy: +Alex Shpilkin

___
Python tracker 

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

[issue43155] PyCMethod_New not defined in python3.lib

[Barry Alan Scott]

Barry Alan Scott  added the comment:

Thanks Petr, I'll watch for the PEP.

FYI: I work on the assumption that if I use Py_LIMITED_API and the header
files provide an API guarded by an #if then its "offical".

--

___
Python tracker 

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

[issue43213] Shortcut for checking if PurePath object contains str

[Tomas Gustavsson]

Tomas Gustavsson  added the comment:

Sorry Serhiy, missed your answer there. I understand your point. I guess
I'll have to look for other things to help with :)

Thank you for the answer.

Guess this can be closed then.

Best regards
Tomas

On Sat, 13 Feb 2021, 12:57 Serhiy Storchaka  wrote:

>
> Serhiy Storchaka  added the comment:
>
> Path is not string, and it was made not string-like intentionally.
> Otherwise it would be made a subclass of str.
>
> If you want to check whether a string is a substring of the string
> representation of the path, just do it explicitly: 'share' in str(path).
> But in most cases it is not what the user intended.
>
> There were several propositions about implementing "in" (and iteration,
> these operations are related and should be consistent). The problem is that
> there several different meaning of that operation. Should it check that the
> directory referred by the path contains the specified file name? Or that
> the path contains the specified path component? Or that one path is a
> subpath of other path? Or that the specified string is a substring of the
> string representation of the path? (The latter proposition is the least
> useful.) It is better to avoid ambiguity, so all these proposition were
> rejected.
>
> --
> nosy: +serhiy.storchaka
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue43213] Shortcut for checking if PurePath object contains str

[Tomas Gustavsson]

Tomas Gustavsson  added the comment:

Okay, maybe a bad example. But let's say I want to find all folders and
files but filter out those which contains .git,.svn in the paths.

Anyhow, I believe this minor feature would make such use cases (and other)
more clean and intuitive. I am lazy and I like when things work without me
having to write more lines or characters then I need.

On Sat, 13 Feb 2021, 12:08 Vedran Čačić  wrote:

>
> Vedran Čačić  added the comment:
>
> While it might be useful, I don't think it is what you want. For example,
> you wouldn't say it contains 'r/sh', right? I think it should only refer to
> full names of path parts.
>
> --
> nosy: +veky
>
> ___
> Python tracker 
> 
> ___
>

--
title: Shortcut for checking if  PurePath object contains str -> Shortcut for 
checking if PurePath object contains str

___
Python tracker 

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

[issue43213] Shortcut for checking if PurePath object contains str

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Path is not string, and it was made not string-like intentionally. Otherwise it 
would be made a subclass of str.

If you want to check whether a string is a substring of the string 
representation of the path, just do it explicitly: 'share' in str(path). But in 
most cases it is not what the user intended.

There were several propositions about implementing "in" (and iteration, these 
operations are related and should be consistent). The problem is that there 
several different meaning of that operation. Should it check that the directory 
referred by the path contains the specified file name? Or that the path 
contains the specified path component? Or that one path is a subpath of other 
path? Or that the specified string is a substring of the string representation 
of the path? (The latter proposition is the least useful.) It is better to 
avoid ambiguity, so all these proposition were rejected.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue43213] Shortcut for checking if PurePath object contains str

[Vedran Čačić]

Vedran Čačić  added the comment:

While it might be useful, I don't think it is what you want. For example, you 
wouldn't say it contains 'r/sh', right? I think it should only refer to full 
names of path parts.

--
nosy: +veky

___
Python tracker 

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

[issue41374] socket.TCP_* no longer available with cygwin 3.1.6+

[Christoph Reiter]

Christoph Reiter  added the comment:

ping. The PR looks good to me.

--

___
Python tracker 

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

[issue43146] 3.10a5 regression: AttributeError: 'NoneType' object has no attribute '__suppress_context__' in traceback.py

[Miro Hrončok]

Miro Hrončok  added the comment:

JFYI, there are 2 affected Fedora packages (that we know of):

visidata fails to build with Python 3.10: AttributeError: 'NoneType' object has 
no attribute '__suppress_context__'
https://bugzilla.redhat.com/show_bug.cgi?id=1928145

python-utils fails to build with Python 3.10: AttributeError: 'NoneType' object 
has no attribute '__suppress_context__'
https://bugzilla.redhat.com/show_bug.cgi?id=1928081

--
nosy: +hroncok

___
Python tracker 

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

[issue43214] site: Potential UnicodeDecodeError when handling pth file

[Inada Naoki]

Change by Inada Naoki :


--
keywords: +easy

___
Python tracker 

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

[issue43214] site: Potential UnicodeDecodeError when handling pth file

[Inada Naoki]

New submission from Inada Naoki :

https://github.com/python/cpython/blob/4230bd52e3f9f289f02e41ab17a95f50ed4db5a6/Lib/site.py#L160

```
f = io.TextIOWrapper(io.open_code(fullname))
```

When default text encoding is not UTF-8 and pth file contains non-ASCII 
character, it will raise UnicodeDecodeError.

--
components: Library (Lib)
keywords: 3.8regression
messages: 386916
nosy: methane
priority: normal
severity: normal
status: open
title: site: Potential UnicodeDecodeError when handling pth file
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 

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