RE: learning python ...

[Avi Gross via Python-list]

I have studied many programming languages and am amused when people attack 
python as if every other language is somehow more optimal.

Cameron and others have provided examples but look at positives AND negatives.

Yes code like: num = int(num)

does look a tad off as it reuses the same name for something that is actually 
in many ways different. You could easily use a new name. But then you would 
have TWO variables in your name space and the old one would not be garbage 
collected unless you explicitly removed it. If you follow this path, would you 
suggest not writing: X = X + 1 either? 

It is actually a fairly common practice in many languages to have code like 
this:

Var = read in something from a file and make some structure like a data.frame
Var = remove some columns from the above thing pointed to by Var
Var = make some new calculated columns ditto
Var = remove some rows ...
Var = set some kind of grouping on the above or sort it and so on.

As you go along you may keep transforming but have no need for earlier results, 
just the new and improved one. So why keep changing names? Some languages 
support not having any names for intermediate results by using nested function 
calls or pipelines.

The reality is that most languages have a series of what I loosely would call 
environments or name tables and as they run, new ones regularly get created and 
removed and even the order of them may change. The algorithm for searching for 
a name varies and can be in some sense linear or more complex. When looking in 
context for a function name, you may follow a different trail or the same one 
as for a variable holding a string and in some implementations the same name 
shadows and in others does not. Wait till you try to figure out the diamond 
pattern of inheritance when you create classes that depend on multiple other 
classes ad nauseum and you try to call a method and it tries to find the one 
you wanted by searching backwards in an interesting way. Many other languages 
decided to just not allow multiple inheritance!

How can you write a recursive function without this kind of variable shadowing? 
Each invocation of a function places the internal namespace in front of the 
parent so the meaning of a variable name used within is always backed by  all 
the iterations before it. But with some kinds of closures, a function may be 
gone and yet variables it had within it persists. Lots of odd examples more 
make this a complex set of CHOICES. 

So what if you suggest we allow re-use of names but WARN you. OK, Python is a 
largely interpreted language. Normally if you ask to use a variable called X, 
it starts a search in the nearest place then the next one and so on till it 
finds it or fails. In many programs, variables are fairly local and found 
easily. But if you want, you can search dozens or hundreds of places and find 
each and every use of X visible at THIS moment and tell the user there are 82 
places it can be seen and here they are. Now what? The first 50 places may be 
in other instances of the recursive function and you have already been warned 
this way 49 times and soon will be warned a few more as it continues to recurse 
as it travels down a tree or graph structure quite legitimately. Some of the 
other  places X may be in use are in some package in a part you are not even 
using indirectly or in middle of a for-loop as a token variable and so on. I 
suspect that 99.99% of the time re-using a name has no negative consequence. 
Making someone keep choosing names like X12346 because there is somewhere an 
X12345 seems a tad silly. But why go to all that expense at run-time versus in 
some lint program?

I recently studied a language called GO that goes to some length to protect  
the user from themselves and often at great expense to getting programming 
done. It won't compile a program if it declares a variable and does not use it. 
Fair enough but I often want to write a sort of shell of a program and check as 
I go to make sure it works before adding more. If I will need 5 variables, I 
might declare them up-front then work on interactions and calculations that 
only include some of them and later I plan on connecting the rest. Nope, it 
won't let me unless I use it as in a print statement or comment it out or just 
remove it. Ah, but then it is not happy I did not initialize it so I set it to 
zero or something. Later, when I finally use it as intended, I need to remove 
the junk. 

Some of this annoyance is so common that they had to come up with a way to shut 
it up. Consider this line:

Result, err = functionA(args)

It returns two arguments. Sometimes it seems silly to worry about the error but 
you MUST write a line of code like:

If (err != nil) {
Do_something
}

Other times you just care if it worked and don't want the result. So placing an 
_ for one or the other is a signal to shut the darn compiler up that you are 
DELIBERATELY ignoring the return value you did not 

[issue44227] help(bisect.bisect_left)

[Mallika Bachan]

Mallika Bachan  added the comment:

Conceptually, yes, but the function does return an index, and values are
stored at these indices. The index it returns holds the leftmost occurrence
of the target (should the target exist)
>>> bisect.bisect_left([1,2,2,3],2)
1
If we insert at this index, it will push the current value right, so
conceptually, sure, it can help to think of the insertion point as being
just before the leftmost target value.

But while bisect_right does in fact return value i that "points just beyond
the rightmost x already there" ("just beyond" gets interpreted as "the next
one", because only whole indices are used), making the statement "i points
just before the leftmost x already there" for the return value of
bisect_left definitely appears incorrect.

On Mon, May 24, 2021 at 6:30 PM Raymond Hettinger 
wrote:

>
> Raymond Hettinger  added the comment:
>
> I there is a misunderstanding here.  The bisect functions never point *to*
> a value.  Instead, they are documented to return "insertion points".  Those
> always occur just before or after a specific value:
>
> values:  10   20   30   30   30   40   50
> insertion points:   |   |||||||
> 0   1234567
> bisect_left(30) -^
> bisect_right(30) ---^
>
> As you can see, bisect_left() does in fact point JUST BEFORE the 30.
>
> Note this is also how slicing works.  Here's an example:
>
> >>> from bisect import bisect_left, bisect_right
> >>> s = [10, 20, 30, 30, 30, 40, 50]
> >>> i = bisect_left(s, 30)
> >>> j = bisect_right(s, 30)
> >>> s[i : j]
> [30, 30, 30]
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue40172] ZipInfo corrupts file names in some old zip archives

[Daniel Hillier]

Daniel Hillier  added the comment:

zipfile decodes filenames using cp437 or unicode and encodes using ascii or 
unicode. It seems like zipfile has a preference for writing filenames in 
unicode rather than cp437. Is zipfile's preference for writing filenames in 
unicode rather than cp437 intentional?

Is the bug you're seeing related to using zipfile to open and rewrite old zips 
and not being able to open the rewritten files in an old program that doesn't 
support the unicode flag?

We could address this two ways:
- Change ZipInfo._encodeFilenameFlags() to always encode to cp437 if possible
- Add a flag to write filenames in cp437 or unicode, otherwise the current 
situation of ascii or unicode

I guess the choice will depend on if preferring unicode rather than cp437 is 
intentional and if writing filenames in cp437 will break anything (it shouldn't 
break anything according to Appendix D of 
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT)

Here's a test for your current patch (I'd probably put it alongside 
OtherTests.test_read_after_write_unicode_filenames as this test was adapted 
from that one)

class OtherTests(unittest.TestCase):
...

def test_read_after_write_cp437_filenames(self):
fname = 'test_cp437_é'
with zipfile.ZipFile(TESTFN2, 'w') as zipfp:
zipfp.writestr(fname, b'sample')

with zipfile.ZipFile(TESTFN2) as zipfp:
zinfo = zipfp.infolist()[0]
# Ensure general purpose bit 11 (Language encoding flag
# (EFS)) is unset to indicate the filename is not unicode
self.assertFalse(zinfo.flag_bits & 0x800)
self.assertEqual(zipfp.read(fname), b'sample')

--
nosy: +dhillier

___
Python tracker 

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

Re: learning python ...

[Cameron Simpson]

On 25May2021 06:08, hw  wrote:
>On 5/25/21 12:37 AM, Greg Ewing wrote:
>>If you rebind a name, and it held the last reference to an
>>object, there is no way to get that object back.
>
>Are all names references?

Yes.

>When I pass a name as a parameter to a function, does the object the 
>name is referring to, when altered by the function, still appear 
>altered after the function has returned?  I wouldn't expect that ...

Yes. Please ready the language specification. This is basic to Python's 
function.

>>On the other hand, if you shadow a name, the original name
>>still exists, and there is usually some way to get at it,
>>e.g.
>>
>> >>> int = 42
>> >>> int
>>42
>> >>> __builtins__.int
>>
>> >>>
>>
>
>You mean built-in objects never go away, even when they are no longer 
>referenced?

Well, the builtins module itself has a reference. But what greg's 
showing you above it the "int" class/type. You've got an in in play in 
the code above - the class will of course exist. But the builtin classes 
(and other names) always exist because they're built in.

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

Re: learning python ...

[Cameron Simpson]

On 25May2021 05:53, hw  wrote:
>That seems like an important distinction.  I've always been thinking of 
>variables that get something assigned to them, not as something that is 
>being assigned to something.

They are what you thought. But it's references to objects what are being 
passed around.  C is a deliberately "close to the machine" language, and 
things a CPU can store in a register are natural types (ints of various 
sizes, etc). But consider a C string:

char *s = "foo";

The compiler here allocates some char storage, puts "foo\0" in it, and 
puts a reference in "s".

char *t = strcpy(s)
char *t2;
t2 = s;
t2 = t;

Here "s", "t" and "t2" are all of type (char*), and store references.  
When you pass "s" or "t" around, eg as above in an assignment, or when 
you pass it to a function, you're not copying the storage, just the 
reference.

Same with Python, except that all the basic types like int and float are 
also done with references.

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

[issue43109] When using Apple Clang, --with-lto builds should not check for llvm-ar

[Ned Deily]

Ned Deily  added the comment:


New changeset 3af61a7176a68bfeb349eeed314b9c3d7ebc3ad5 by Miss Islington (bot) 
in branch '3.9':
bpo-43109: Fix --with-lto configure option on macOS (GH-26341) (GH-26343)
https://github.com/python/cpython/commit/3af61a7176a68bfeb349eeed314b9c3d7ebc3ad5


--

___
Python tracker 

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

[issue43109] When using Apple Clang, --with-lto builds should not check for llvm-ar

[miss-islington]

miss-islington  added the comment:


New changeset 25a9cf197ea0d77abd49992a7751efa0046bb1e6 by Miss Islington (bot) 
in branch '3.10':
bpo-43109: Fix --with-lto configure option on macOS (GH-26341)
https://github.com/python/cpython/commit/25a9cf197ea0d77abd49992a7751efa0046bb1e6


--

___
Python tracker 

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

Re: learning python ...

[hw]

On 5/25/21 12:37 AM, Greg Ewing wrote:

On 25/05/21 9:27 am, Cameron Simpson wrote:

On 24May2021 16:17, hw  wrote:

 >

Or it doesn't forget
about the old one and the old one becomes inaccessible (unless you
have a reference to it, if there is such a thing in python).  How do
you call that?


You're conflating values
(objects, such as an int or a string) with variables (which _are_
references in Python,


I think hw might have meant the C++ notion of a reference to
a *variable*. There is no equivalent of that in Python.


yes, or a reference in perl


Python does have references to *objects*. All objects live on
the heap and are kept alive as long as there is at least one
reference to them.

If you rebind a name, and it held the last reference to an
object, there is no way to get that object back.


Are all names references?  When I pass a name as a parameter to a 
function, does the object the name is referring to, when altered by the 
function, still appear altered after the function has returned?  I 
wouldn't expect that ...



On the other hand, if you shadow a name, the original name
still exists, and there is usually some way to get at it,
e.g.

 >>> int = 42
 >>> int
42
 >>> __builtins__.int

 >>>



You mean built-in objects never go away, even when they are no longer 
referenced?

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

[issue44151] Improve parameter names and return value ordering for linear_regression

[Raymond Hettinger]

Change by Raymond Hettinger :


--
pull_requests: +24936
pull_request: https://github.com/python/cpython/pull/26344

___
Python tracker 

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

[issue5758] fileinput.hook_compressed returning bytes from gz file

[Inada Naoki]

Inada Naoki  added the comment:

> I'm struggling with how to adapt the code to provide a uniform interface on 
> Python 3.6+.

It's easy. Just passing `mode="rb"`.

```
FileInput(filelist, mode="rb", openhook=fileinput.hook_compressed)
```

This is better than `backports.hook_compressed`, because it returns bytes 
always regardless file is compressed or uncompressed.

--

___
Python tracker 

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

Re: learning python ...

[hw]

On 5/24/21 4:28 PM, Michael Torrie wrote:

On 5/24/21 8:17 AM, hw wrote:

What does python actually do in the first example?  Does it overshadow a
variable or does it change one?  If it overshadows a variable, it would
be dubious, if it doesn't, it won't be dubious.


Are you referring to this?

   num = input("Enter a number: ")
   num = int(num)


yes


No it is not "overshadowing" a variable.  You cannot get back to the
original string value for num.


So the other example that uses a second variable to avoid possible 
ambiguity could be considered as bloating because it keeps both 
variables around.



There are more alternatives:  Python might create a new variable with
the same name and forget about the old one.  Or it doesn't forget about
the old one and the old one becomes inaccessible (unless you have a
reference to it, if there is such a thing in python).  How do you call that?


Python variables are not memory boxes like in a compiled language.  They
are names bound to objects, as Mr Simpson alluded to.


That seems like an important distinction.  I've always been thinking of 
variables that get something assigned to them, not as something that is 
being assigned to something.



So in the first
line, the name num is bound to a string.  In the second line, the name
is re-bound to an int object.


I would think of it as assigning a string to a variable and then 
changing the content of the variable by assigning something else to the 
same variable.  When variables are typeless, it doesn't matter if a 
string or an integer is assigned to one (which is weird but can be very 
useful).


It seems much more practical to assign different strings to the same 
variable rather than assigning a different variable to each string, or 
to assign a string to a variable and then to assign an integer to it.


Isn't that what variables are for?


Furthermore, if num had come from the
global name scope, either of these lines would create a local name num
that does shadow the name from the global scope.

Hope that helps.




Yes, I guess it will be interesting not to think of variables but of 
objects.

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

Re: learning python ...

[hw]

On 5/24/21 4:37 PM, Chris Angelico wrote:

On Tue, May 25, 2021 at 12:31 AM Michael Torrie  wrote:


On 5/24/21 8:24 AM, Chris Angelico wrote:

On Tue, May 25, 2021 at 12:18 AM hw  wrote:

There are more alternatives:  Python might create a new variable with
the same name and forget about the old one.  Or it doesn't forget about
the old one and the old one becomes inaccessible (unless you have a
reference to it, if there is such a thing in python).  How do you call that?


It's the latter option: create a new variable, and the old one becomes
inaccessible. That's called "shadowing". It's how scoping works in
most languages (called "lexical scope").


Is it really shadowing, though?  The old one is not only inaccessible,
it's possibly reaped by the garbage collector, no?  Both nums are in the
same scope so the one overwrote the other in the name table.  Or am I
missing something.



We're talking about many different things. If it's simply "num = ..."
followed by "num = ...", then it's not a new variable or anything,
it's simply rebinding the same name. But when you do "int = ...", it's
shadowing the builtin name.


Why?  And how is that "shadowing"?

What if I wanted to re-define the built-in thing?
--
https://mail.python.org/mailman/listinfo/python-list

[issue44227] help(bisect.bisect_left)

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> not a bug
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

[issue42194] Docs for argparse.BooleanOptionalAction missing "New in version 3.9"

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> How can we proceed with this doc fix?

Just make a new PR.  I'll check it in and close the old one.

--

___
Python tracker 

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

[issue42194] Docs for argparse.BooleanOptionalAction missing "New in version 3.9"

[John Belmonte]

John Belmonte  added the comment:

A PR was opened over a year ago, but the author never signed CLA.

How can we proceed with this doc fix?

--
nosy: +John Belmonte

___
Python tracker 

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

Re: learning python ...

[hw]

On 5/24/21 4:41 PM, Michael Torrie wrote:

On 5/24/21 8:21 AM, Michael Torrie wrote:

Given your posts thus far, hw, I don't think Python is a good fit for
you. You're better off learning a language that more closely aligns with
the statically-typed languages you already know.


Maybe it is, maybe it isn't; I've been thinking about it for a while now.


That was unnecessarily harsh; my apologies.  I can see now that you
might be comparing some features to Perl, which is a more dynamic
language.  I see in your recent posts that you are trying to understand
how Python works, and that is good.  Hopefully you'll find Python a
dynamic and useful tool.  If not, that's perfectly okay. Use the right
tool for the job.



That's what I'm trying to do.  I'm just using a particular problem I 
want to solve as an occassion to maybe learn python because it seems 
much easier to solve in python than in perl.


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

[issue43109] When using Apple Clang, --with-lto builds should not check for llvm-ar

[miss-islington]

Change by miss-islington :


--
pull_requests: +24935
pull_request: https://github.com/python/cpython/pull/26343

___
Python tracker 

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

[issue43109] When using Apple Clang, --with-lto builds should not check for llvm-ar

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +24934
pull_request: https://github.com/python/cpython/pull/26342

___
Python tracker 

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

Re: learning python ...

[hw]

On 5/24/21 3:54 PM, Chris Angelico wrote:

On Mon, May 24, 2021 at 11:35 PM hw  wrote:


On 5/24/21 9:52 AM, Chris Angelico wrote:

Does C give you a warning if you create a function-local variable
called "printf"? No, and it shouldn't. Does any other language
complain if you use its scoping rules to reuse a name? Nope. Does
Python? As above, no.


Try the equivalent of above python in C:


void foo(void) {
  int int = 25;
  printf("int: %d\n", int);
}

int main(int argc, char **argv) {
  foo();
}


I did specifically mention "printf", which works just fine, as you see below.


see below


I don't know which C compiler you're using; gcc doesn't compile this and
gives several error messages.  Python quietly allows things like this
without any warning at all, and I'm saying that's a bad thing and that
python seems unfinished because it doesn't even give a warning in cases
like this.


You keep using that word "unfinished". I do not think it means what
you think it does.


What do you think I think it means?


Python has keywords. C has keywords. In Python, "None" is a keyword,
so you can't assign to it; in C, "int" is a keyword, so you can't
assign to it. There is no fundamental difference here, and the two
languages even have roughly the same number of keywords (35 in current
versions of Python; about 40 or 50 in C, depending on the exact
specification you're targeting). The only difference is that, in
Python, type names aren't keywords. You're getting caught up on a
trivial difference that has happened to break one particular test that
you did, and that's all.


Then what is 'float' in the case of isinstance() as the second 
parameter, and why can't python figure out what 'float' refers to in 
this case?  Perhaps type names should be keywords to avoid confusion.



I don't know REXX, and I'm not sure what the equivalent would be in
elisp.  The issue doesn't exist in perl.  It may be intentionally so
that python makes it easy to defeat fundamental aspects of the language
simply by, accidentially or intentionally, re-defining them without
warning, and even if that is so, nobody else has to like a feature like
that just because you do like it.


REXX doesn't have keywords at all. (It has language syntax words, but
everything is contextual, so you can quite happily say "if = 1" and
then "if if" becomes valid.) Perl has keywords, just like everything
else, but not for data types.

This is NOT something fundamental to the language that is "defeated".
You have made it harder to perform isinstance checks, but that's
neither fundamental nor defeated by this shadowing. The integer type
still exists - you just made a new variable with the name "int". The
float type still exists - you just made a new variable with the name
"float".


Ok, that is an important difference.


Maybe you can show how this is a likeable feature.  I already understood
that you can somehow re-define functions in python and I can see how
that can be useful.  You can do things like that in elisp as well.  But
easily messing up built-in variable types like that is something else.
Why would I want that in a programming language, and why would I want to
use one that allows it?


Because all you did was mess with the *name* of the type. It's not
breaking the type system at all.


And how is it a likeable feature?


Most Python programs manage just fine
without ever doing an isinstance check, and even if you do have to,
it's possible to refer to the type in other ways:


(1).__class__




int = 42
isinstance(int, (1).__class__)

True

See? Not broken. All you did was change the meaning of the name "int",
by assigning to it.


No, but I take your word for it.


Your claim that I'm insulting python or anoyone is ridiculous.
According to your logic, C is insulting python.  I suggest you stop
making assumptions.


The C language never says that Python is "unfinished". I'm not making
assumptions, I'm reading your posts.


I never said it is unfinished, I said it /seems/ unfinished.  In any 
case, there is nothing insulting about it.  Python is still being worked 
on (which is probably a good thing), and the switch from version 2 to 
version 3 has broken a lot of software, which doesn't help in making it 
appear as finished or mature.



The example you want is probably this one:


#include 

void foo(void) {
  int printf = 25;
  printf("int: %d\n", printf);
}

int main(int argc, char **argv) {
  foo();
}


Perhaps you can't see how both examples are different because you're
looking at things from a python perspective.


Well, look at them from a language design perspective and tell me how
different they really are.


Just look at what the compiler says when you try to compile these 
examples.  In the first example, you can't defeat a built-in data type 
by assigning something to it, and in the second one, you declare 
something as an instance of a build-in data type and then try to use it 
as a function.  That is so because the 

[issue5758] fileinput.hook_compressed returning bytes from gz file

[Jason R. Coombs]

Jason R. Coombs  added the comment:

A backport now exists (https://pypi.org/project/backports.hook_compressed) and 
addresses the issue (https://github.com/jaraco/cmdix/actions/runs/873404846).

--

___
Python tracker 

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

[issue5758] fileinput.hook_compressed returning bytes from gz file

[Jason R. Coombs]

Jason R. Coombs  added the comment:

The patch for this change has broken code that relied on the old behavior. For 
example:

```
import fileinput
import bz2
import pathlib

target = pathlib.Path('data.bz2')
target.write_bytes(bz2.compress(b'Foo\nBar\nBiz'))

inp = fileinput.FileInput([str(target)], openhook=fileinput.hook_compressed)
for line in inp:
print(line.decode().strip())
```

That code passes on Python3.10a6 but on 3.10b1 fails with:

```
Traceback (most recent call last):
  File "/Users/jaraco/code/main/cmdix/text.py", line 10, in 
print(line.decode().strip())
AttributeError: 'str' object has no attribute 'decode'. Did you mean: 'encode'?
```

I encountered this issue in [this function and its 
test](https://github.com/jaraco/cmdix/blob/dc5fac3817ff9815b2f8d9a1dfad4258c14b1693/cmdix/lib.py#L165-L193).

I'm struggling with how to adapt the code to provide a uniform interface on 
Python 3.6+. Perhaps a backport of hook_compressed is in order.

--
nosy: +jaraco

___
Python tracker 

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

[issue44227] help(bisect.bisect_left)

[Mallika Bachan]

Change by Mallika Bachan :


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

___
Python tracker 

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

[issue44093] compiler detection on macOS seems to be incorrect

[Ned Deily]

Change by Ned Deily :


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

___
Python tracker 

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

[issue43109] When using Apple Clang, --with-lto builds should not check for llvm-ar

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +24931
pull_request: https://github.com/python/cpython/pull/26341

___
Python tracker 

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

[issue44120] logging.config.fileConfig/dictConfig can not import class

[Hiroaki Mizuguchi]

Hiroaki Mizuguchi  added the comment:

I understand. I am mistaken about class loading. I will withdraw this issue.

--

___
Python tracker 

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

[issue44228] [urllib] Error with handling of urllib.parse.quote. Terminates halfway

[Swee Tat Lim]

New submission from Swee Tat Lim :

Running this

python3 -c "import urllib.parse; print 
(urllib.parse.quote('ab$cd#hij$klm'))"

Results:
ab%26efg%23hij

Expected Result:
ab%26efg%23hij%26klm

Not sure why it terminated midway

--
components: Library (Lib)
messages: 394284
nosy: sweetat
priority: normal
severity: normal
status: open
title: [urllib] Error with handling of urllib.parse.quote.  Terminates halfway
versions: Python 3.10, Python 3.11, 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

[issue44227] help(bisect.bisect_left)

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I there is a misunderstanding here.  The bisect functions never point *to* a 
value.  Instead, they are documented to return "insertion points".  Those 
always occur just before or after a specific value:

values:  10   20   30   30   30   40   50
insertion points:   |   |||||||
0   1234567
bisect_left(30) -^
bisect_right(30) ---^

As you can see, bisect_left() does in fact point JUST BEFORE the 30.

Note this is also how slicing works.  Here's an example:

>>> from bisect import bisect_left, bisect_right
>>> s = [10, 20, 30, 30, 30, 40, 50]
>>> i = bisect_left(s, 30)
>>> j = bisect_right(s, 30)
>>> s[i : j]
[30, 30, 30]

--

___
Python tracker 

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

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Here's my two cents worth on the subject.  

* I use hypothesis during development, but don't have a need for in the the 
standard library.  By the time code lands there, we normally have a specific 
idea of what edge cases needs to be in the tests.

* For the most part, hypothesis has not turned up anything useful for the 
standard library.  Most of the reports that we've gotten reflected a 
misunderstanding by the person running hypothesis rather than an actual bug.  
For example, in colorsys, an issue was reported about the color conversions not 
round-tripping, but that is an expected behavior for out of gamut conversions.  
Also, the matrices used are dictated by standards and do not give exact 
inverses even for in gamut conversions.

* For numeric code, hypothesis is difficult to use and requires many 
restrictions on the bounds of variables and error tolerances.  For example, 
when I have students with a function to evaluate the quadratic formula and test 
it with hypothesis, they struggle mightily (overflowing the discriminant, 
having 2*a close to zero, deciding whether the roots are sufficiently close, 
etc.)

* The main area where hypothesis seems easy to use and gives some comfort is in 
simple roundtrips:  assert zlib.decompress(zlib.compress(s)) == s.  However, 
that is only a small fraction of our test cases.

* Speed is another issue.  During development, it doesn't matter much if 
Hypothesis takes a lot of time exercising one function.  But in the standard 
library tests already run slow enough to impact development.  If hypothesis 
were to run everytime we run a test suite, it would make the situation worse.

* There is also a learning curve issue.  We're adding more and more things that 
newcomer's have to learn before they can contribute (how to run blurb, how to 
use the argument clinic, etc).  Using Hypothesis is a learned skill and takes 
time.

TL;DR  I really like Hypothesis but think it doesn't belong in standard library 
tests.

--
nosy: +rhettinger

___
Python tracker 

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

Re: learning python ...

[Jon Ribbens via Python-list]

On 2021-05-24, Alan Gauld  wrote:
> On 24/05/2021 16:54, Michael F. Stemper wrote:
>
>> In my early days of writing python, I created lists named "list",
>> dictionaries named "dict", and strings named "str". I mostly know better
>> now, but sometimes still need to restrain my fingers.
>
> I think most newbie programmers make that mistake. I certainly
> did when learning Pascal back in the 80's.
>
> But I was lucky, the tutorials were run by a guy who penalized
> bad variable names severely and took a half-mark off for every
> bad name. We very quickly learned to choose names that were
> descriptive of the purpose rather than the type.

Tricky when you're writing general utility functions.
What would you call the argument to a function that
returns, say, an upper-cased version of its input?
(Pretending for a moment that Python didn't already
have such a function built-in ;-) )

I mean, sure, you could call it "inputString" or
something but that sort of thing gets annoyingly
verbose very quickly. If you're using type
annotations then "input: str" would be ok but if
you're not then just "input" is overly opaque
(not to mention shadowing a builtin).

This is why it's good when languages have conventions
like "types and classes start with an upper-case letter",
so that you can do "string = String()" without problems...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Alan Gauld via Python-list]

On 24/05/2021 19:48, Grant Edwards wrote:

>> Traceback (  File "", line 1
>> if = 1.234
>>^
>> SyntaxError: invalid syntax
> 
> I must admit it might be nice if the compiler told you _why_ the
> syntax is invalid (e.g. "expected conditional expression while parsing
> 'if' statement").

Although wouldn't it be "expected boolean expression" rather than
conditional expression? Python doesn't care how the argument  to 'if'
is arrived at so long as it's a boolean. And with assignment
expressions, conditional expressions and literals all possible
unambiguous error messages get harder and harder to figure out.

But I do accept the general point that slightly more information
about syntax errors would be nice.

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

[issue44151] Improve parameter names and return value ordering for linear_regression

[Raymond Hettinger]

Change by Raymond Hettinger :


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

[issue44227] help(bisect.bisect_left)

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue44151] Improve parameter names and return value ordering for linear_regression

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 86779878dfc0bcb74b4721aba7fd9a84e9cbd5c7 by Miss Islington (bot) 
in branch '3.10':
bpo-44151: linear_regression() minor API improvements (GH-26199) (GH-26338)
https://github.com/python/cpython/commit/86779878dfc0bcb74b4721aba7fd9a84e9cbd5c7


--

___
Python tracker 

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

[issue44227] help(bisect.bisect_left)

[Mallika Bachan]

New submission from Mallika Bachan :

Documentation issue.

help(bisect.bisect_left)
says: "... if x already appears in the list, i points just before the leftmost 
x already there."
but in fact, it actually points *to* the leftmost x already there

--
messages: 394280
nosy: mallika.bachan
priority: normal
severity: normal
status: open
title: help(bisect.bisect_left)
type: behavior
versions: Python 3.11

___
Python tracker 

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

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

[Guido van Rossum]

Guido van Rossum  added the comment:

I withdraw my objection against Hypothetlsis per se. Others should debate
whether the 3rd party dependency is okay. --
--Guido (mobile)

--

___
Python tracker 

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

[issue44151] Improve parameter names and return value ordering for linear_regression

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +24930
pull_request: https://github.com/python/cpython/pull/26338

___
Python tracker 

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

[issue44206] Add a version number to dict keys.

[STINNER Victor]

STINNER Victor  added the comment:

Can't you please explain which kind of optimizations do you want to implement 
using such dict key version?

--

___
Python tracker 

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

RE: Question for potential python development contributions on Windows

[pjfarley3]

> -Original Message-
> From: Terry Reedy 
> Sent: Sunday, May 23, 2021 10:05 PM
> To: python-list@python.org
> Subject: Re: Question for potential python development contributions on
> Windows
 
> I am pretty sure that VS2019 output is binary compatible with with output from
> VS2017 and VS2015.  I believe the only issue would be is one were developing a
> patch to a CPython .c file and one used recent C## features not allowed in
> CPython code.
> 
> You could open an issue on bugs.python.org asking that the doc be clarified.

I have received several positive answers on the python-dev list since I posted 
the question here.  The answer is yes, VS2019 and all VS20xx releases since 
VS2015 are correct to use for Windows contributions until MS changes the binary 
C/C++ ABI, currently at level V14x.

The core dev's have indicated that the Python Development Guide documentation 
needs updating to reflect this fact.

Peter

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

[issue41282] Deprecate and remove distutils

[Ned Deily]

Ned Deily  added the comment:

Petr's analysis and PR looked good and the PR is now merged to main and to 3.10 
for 3.10.0b2.  Thanks, Petr! Downgrading back to normal priority.

--
priority: release blocker -> normal

___
Python tracker 

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

[issue38908] Troubles with @runtime_checkable protocols

[miss-islington]

Change by miss-islington :


--
pull_requests: +24929
pull_request: https://github.com/python/cpython/pull/26337

___
Python tracker 

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

Re: learning python ...

[Alan Gauld via Python-list]

On 24/05/2021 16:54, Michael F. Stemper wrote:

> In my early days of writing python, I created lists named "list",
> dictionaries named "dict", and strings named "str". I mostly know better
> now, but sometimes still need to restrain my fingers.

I think most newbie programmers make that mistake. I certainly
did when learning Pascal back in the 80's.

But I was lucky, the tutorials were run by a guy who penalized
bad variable names severely and took a half-mark off for every
bad name. We very quickly learned to choose names that were
descriptive of the purpose rather than the type.

Its a lesson that I've never forgotten!

-- 
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: learning python ...

[Dan Stromberg]

On Sun, May 23, 2021 at 12:35 PM hw  wrote:

> I don't know about shadowing.  If I have defeated a whole variable type
> by naming a variable like a variable type, I would think it is a bad
> idea for python to allow this without warning.  It seems like a recipie
> for creating chaos.
>

It strikes me as a pretty natural consequence of types being first class
objects in Python.  There's a little unlearning to do if you're coming from
a more traditional language, but it's not difficult once you know how
Python does its thing.

Have you ever tried to put int (not an int, the type int) in a variable in
C?  You can sort of do it with the C PreProcessor, but that's always been a
bit of a kludge.

IOW, in Python everything is an object.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue40222] "Zero cost" exception handling

[Guido van Rossum]

Guido van Rossum  added the comment:

Ah, okay. So we're not on the hook to decide this today. :-)

--

___
Python tracker 

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

[issue41282] Deprecate and remove distutils

[miss-islington]

miss-islington  added the comment:


New changeset 1c454eb2e4eb9e08ee94920c0e1ca7c8896371ec by Miss Islington (bot) 
in branch '3.10':
bpo-41282: Fix broken `make install` (GH-26329)
https://github.com/python/cpython/commit/1c454eb2e4eb9e08ee94920c0e1ca7c8896371ec


--

___
Python tracker 

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

Re: learning python ...

[Greg Ewing]

On 25/05/21 9:27 am, Cameron Simpson wrote:

On 24May2021 16:17, hw  wrote:

>

Or it doesn't forget
about the old one and the old one becomes inaccessible (unless you
have a reference to it, if there is such a thing in python).  How do
you call that?


You're conflating values
(objects, such as an int or a string) with variables (which _are_
references in Python,


I think hw might have meant the C++ notion of a reference to
a *variable*. There is no equivalent of that in Python.

Python does have references to *objects*. All objects live on
the heap and are kept alive as long as there is at least one
reference to them.

If you rebind a name, and it held the last reference to an
object, there is no way to get that object back.

On the other hand, if you shadow a name, the original name
still exists, and there is usually some way to get at it,
e.g.

>>> int = 42
>>> int
42
>>> __builtins__.int

>>>

--
Greg

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

[issue40222] "Zero cost" exception handling

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Small note, as I mentioned in my correction email 
(https://mail.python.org/archives/list/python-...@python.org/message/GBD57CUUU4K5NMQDTEZXNCX76YISEIGQ/),
 this is a release blocker for 3.11 (it was not marked in the issue what Python 
version was associated, I am doing it with this message) so this doesn't block 
the 3.10 release.

--
versions: +Python 3.11

___
Python tracker 

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

[issue40222] "Zero cost" exception handling

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> I think we're waiting here for the release manager to decide, right?

As Petr mentions, the release manager doesn't have authority to decide if the 
backwards compatibility policy can be ignored, only the Steering Council.

> Should we roll back the change to PyCode_NewWithPosOnlyArgs() or keep it?

I don't think is possible: code objects must be constructed with the new 
argument, otherwise they are broken. There is not an easy way to have a default 
for PyCode_New and PyCode_NewWithPosOnlyArgs that somehow creates the field 
from nothing. 

I *personally* think that this case is one good example of an exception to the 
backwards compact rule, but I myself cannot grant that exception as a release 
manager. I also think these APIs should be removed from the public C-API ASAP 
because they literally conflict everytime we change the code object for 
optimizations.

--

___
Python tracker 

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

[issue42392] [document removal of] the deprecated 'loop' parameter asyncio API in 3.10

[Gregory P. Smith]

Change by Gregory P. Smith :


--
title: remove the deprecated 'loop' parameter asyncio API -> [document removal 
of] the deprecated 'loop' parameter asyncio API in 3.10

___
Python tracker 

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

[issue42392] remove the deprecated 'loop' parameter asyncio API

[Gregory P. Smith]

Change by Gregory P. Smith :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python

___
Python tracker 

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

[issue40222] "Zero cost" exception handling

[Guido van Rossum]

Guido van Rossum  added the comment:

I think we're waiting here for the release manager to decide, right? Should we 
roll back the change to PyCode_NewWithPosOnlyArgs() or keep it?

Presumably the requested docs aren't the (beta) release blocker?

--

___
Python tracker 

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

[issue41282] Deprecate and remove distutils

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 21.0 -> 22.0
pull_requests: +24928
pull_request: https://github.com/python/cpython/pull/26336

___
Python tracker 

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

[issue44222] Improving _removeHandlerRef for a very long _handlerList

[Yonatan Goldschmidt]

Yonatan Goldschmidt  added the comment:

That system has many (>10k) objects of a certain type. Each of them has a 
separate Logger object + Handlers. That was done, among other reasons, to allow 
for easy consuming of the logs relating to a particular object in a file-based 
manner.

I agree that it's not common at all (other Python projects I've worked on don't 
exhibit this behavior) but since this change is harmless I thought we might as 
well make it.

--

___
Python tracker 

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

[issue42392] remove the deprecated 'loop' parameter asyncio API

[Gregory P. Smith]

Gregory P. Smith  added the comment:

There appear to be no versionchanged:: 3.10 in the asyncio docs on the APIs 
that formerly accepted a loop= parameter linking people to information on when 
that went away (3.10) and why.  Specifically I'm talking about 
https://docs.python.org/3.10/library/asyncio-stream.html.

The asyncio stack traces people will face when porting code to 3.10 are 
mystifying (they may not even show use of a loop parameter) when this comes up, 
so we should really leave more bread crumbs than expecting people to find the 
What's New doc.

```
...
Eserver = event_loop.run_until_complete(coro)
E  File 
"/opt/hostedtoolcache/Python/3.10.0-beta.1/x64/lib/python3.10/asyncio/base_events.py",
 line 641, in run_until_complete
Ereturn future.result()
E  File 
"/opt/hostedtoolcache/Python/3.10.0-beta.1/x64/lib/python3.10/asyncio/streams.py",
 line 113, in start_unix_server
Ereturn await loop.create_unix_server(factory, path, **kwds)
E  TypeError: _UnixSelectorEventLoop.create_unix_server() got an unexpected 
keyword argument 'loop'
```

Arguably something similar to that whatsnew text should've been added to the 
docs in 3.8 with the loop deprecation.  Something like this?

```
.. versionchanged:: 3.7

   This function now implicitly gets the
   current thread's running event loop.

.. versionchanged:: 3.10
   That `loop` parameter has been removed.
```

including a ReST link to more info in the whats new doc on the last entry would 
be useful.

--
nosy: +gregory.p.smith
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 

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

[issue44079] [sqlite3] remove superfluous statement weak ref list from connection object

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

> I'm not fully sure that the both use cases can be combined.

I'm fully sure they can :) Did I miss anything in msg393942? AFAICS, there is 
no need for the weak ref list anymore.

--

___
Python tracker 

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

Re: learning python ...

[Cameron Simpson]

On 24May2021 16:17, hw  wrote:
>On 5/24/21 11:33 AM, Cameron Simpson wrote:
>>Note that in this function:
>>
>> x = 1
>> y = 2
>>
>> def f(a):
>> x = 3
>> print(x, y)
>>
>>"x" is local, because the function contains an assignment to it. "y"
>>comes from an outer scope (in this case, the global scope) because
>>there's no assignment to it.
>
>Thanks!  That basically works the same as in perl then.

ISTR that Perl needed me to declare locals with my(). Locals are deduced 
from the code in Python.

As Stestagg has mentioned, there are also tools called linters which
warn you about issues like this. Tools like pyflakes, pylint,
pycodestyle all inspect your code for a wide variety of potential errors
and discouraged habits.  Not to mention tools like mypy which do type
validation.
>>>
>>>So you're saying one can't really go without those unless you want to
>>>take the risk?
>>
>>Self restraint and developing good habits does 99% of the work. Linters
>>are great for catching various accidents.
>
>I never needed one before.

I programmed for years in Python (and Perl etc etc) without bothing with 
linters. As I said, 99% of the work can be achieved with a loittle self 
discipline. But linters are good for catching mistakes - computers don't 
get bored. And they can also catch things you weren't considering.

I used to use lint in C and liked the attention to tedious detail.

So for my environment I wrote myself a "lint" script which runs the 
linters I like with the options I like, and linting is now an easy step 
that I perform at my choosing (generally post bug fixing or feature 
implementing).

>>[...]
>>>I'm not saying it shouldn't be allowed to defeat or to re-define stuff,
>>>only that it shouldn't go through quietly.
>>
>>Well, most of us use linters to exhibit that noise, rather than
>>requiring the code to be littered with special directives.
>>
>>I usually code without much linter fuss until I've got the latest batch
>>of work (eg feature or fix) ready, commit the changes, then lint
>>vigorously and commit that polish before merging with the main line of
>>code.
>
>Maybe python requires a different approach than other languages in 
>that it doesn't allow for the overhead that can be used to make things 
>easy to read and without guessing in other languages.  That overhead 
>can be a disadvantage, yet getting to used to not having it could take 
>a while.

The approach isn't required. I find the approach useful to me.

>>Finally, consider this code:
>>
>> num = input("Enter a number: ")
>> num = int(num)
>>
>>input() returns a string, which would need converting to a number before
>>some numeric stuff. Plenty of people write the above. To my mind, this
>>is also a kind of shadowing, and I like this instead:
>>
>> num_s = input("Enter a number: ")
>> num = int(num_s)
>>
>>where the "_s" indicates quietly that this variable holds a string.
>
>Isn't that a kind of overhead python is trying to avoid?

It's a style or work practice of my own choosing. Python itself is happy 
with either code.

>>Is that shadowing to your mind? Or not? If yes, should the language emit
>>noise there, too? Remembering that Python _values_ are strongly typed,
>>though the variables are not (a variable might reference any kind of
>>object, as above).
>
>No, I don't see any shadowing in either example.  In the first one, 
>you (seem to) make sure that you get an integer (not considering what 
>happens when the input is not something that can be cast into an 
>integer) using the same variable by altering its contents.
>
>In the second example, you're using two different variables, trying to 
>cast the first one to an integer while assigning it to a second one 
>which is implicitly declared.
>
>If anything, I could argue that this is convoluted code because you're 
>doing lots of stuff implicitly --- and that could be argued for both 
>examples.  You could make it worse like
>
>  if(int(num = input("foo: ")) == 5):
>pass
>
>involving side effects, but I don't know if python would allow you to 
>do that.  (Not that I would want to do something like this, but it 
>would make sense to me if it could be done ...)
>
>>I wouldn't say that your opinion would be wrong regardless of what side
>>of this question you come down on, but Python's chosen a side: noise for
>>nonsensical things, but not noise for dubious things. But plenty of
>>linters to complain about dubious things.
>
>What does python actually do in the first example?  Does it overshadow 
>a variable or does it change one?  If it overshadows a variable, it 
>would be dubious, if it doesn't, it won't be dubious.

Variables are just names which reference objects. The first example 
causes "num" to reference the string returned by input(), then it causes 
"num" to reference the int returned by int().

If you think of them like C pointers the analogy works well. They're not 
pointers (i.e. they're not memory 

[issue44226] Threads shutting down in Py 2.7 but not in Py 3.69 while making SSH connection using Paramiko module

[Eric V. Smith]

Eric V. Smith  added the comment:

This was reported a few hours ago at 
https://github.com/paramiko/paramiko/issues/1856.

I'm closing this as a third party issue.

--
nosy: +eric.smith
resolution:  -> third party
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

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
nosy: +erlendaasland

___
Python tracker 

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

[issue43853] [sqlite3] Improve sqlite3_value_text() error handling

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

The affected branch is exercised by the following tests:
- test_aggr_check_param_blob
- test_aggr_check_param_float
- test_aggr_check_param_int
- test_aggr_check_param_none
- test_aggr_check_param_str
- test_aggr_check_params_int
- test_aggr_exception_in_finalize
- test_aggr_exception_in_step
- test_aggr_no_finalize
- test_param_string

I've expanded test_aggr_check_param_str and test_param_string to also check 
empty strings.

--

___
Python tracker 

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

[issue42654] Add folder for python customizations: __sitecustomize__

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

[David Edelsohn]

David Edelsohn  added the comment:

It seems that PyOS_AfterFork_Child() needs to do something like

PyThreadState *tstate = PyThreadState_Get();
PyObject *wr = _PyObject_CAST(tstate->on_delete_data);
PyObject *obj = PyWeakref_GET_OBJECT(wr);
lockobject *lock;
if (obj != Py_None) {
lock = (lockobject *) obj;
if (lock->locked) {
/* Leak memory on purpose. */
lock->locked = 0;
}
}

before the call to _PyEval_ReInitThreads.

Maybe encapsulate that as PyThread_ReInitThreads().

The locks in the threads in the child need to be cleared before 
_PyThreadState_DeleteExcept() so that Python does not try to release the locks 
in the child.

--

___
Python tracker 

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

[issue11486] Add option to not install into /Applications

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

Ronald, do you still wish to apply this? It should be easy to rebase this patch 
onto main.

If not, we should perhaps close this issue.

--
nosy: +erlendaasland
versions: +Python 3.11 -Python 3.4

___
Python tracker 

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

Re: Question for potential python development contributions on Windows

[Terry Reedy]

On 5/23/2021 10:05 PM, Terry Reedy wrote:

On 5/23/2021 12:20 PM, pjfarl...@earthlink.net wrote:
I asked this question on python-dev last week but did not get an 
answer.  If

anyone here know the answer I would appreciate it.

The Python Developers Guide specifically states to get VS2017 for 
developing

or enhancing python on a Windows system.

Is it still correct to specifically use VS2017 , or is VS2019 also
acceptable?


pjfarley just got answers on pydev.  For anyone else, they are no, not 
only VS2017, and yes, VS2019 is fine.  The same will be true of a 
possible VS2021 as long as the compiler version remain 14.something.


--
Terry Jan Reedy


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

Re: f-strings and internationalisation.

[Barry Scott]

> On 24 May 2021, at 19:30, Antoon Pardon  wrote:
> 
> I have now come across several occasion where an author advice the use
> of f-strings above the %-formatting and the format method. However it
> seems these authors were only thinking about rather straight forward
> english communication.
> 
> So what if you want your application to work with multiple languages.
> Can that be done with f-strings?

No it cannot be done. This is because a translation can reorder
the parts of the string is drastic ways that f'strings' does not allow for.

You need to use this style:

_('This %(arg1)s and %(arg2)s') % {'arg1': value_arg1, 'arg2': 
value_arg2}

or
_('This {arg1} and {arg2}').format(arg1=value_args, arg2=values_arg2)

A translator would be free to swap arg1 and arg2 order in a translation.

See https://docs.python.org/3/library/gettext.html for more details.
And https://www.mattlayman.com/blog/2015/i18n/ looks useful as well.

Then you can use use the I18N gettext tools to make a .pot and .po files.

Barry
 


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

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

Re: learning python ...

[Grant Edwards]

On 2021-05-24, Dennis Lee Bieber  wrote:

>   Attempting to rebind a keyword in Python will produce an error...
>
 if = 1.234
> Traceback (  File "", line 1
> if = 1.234
>^
> SyntaxError: invalid syntax

I must admit it might be nice if the compiler told you _why_ the
syntax is invalid (e.g. "expected conditional expression while parsing
'if' statement").

It's usually fairly obvious, but...

--
Grant



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

[issue43665] AIX: test_importlib regression (ENV change)

[David Edelsohn]

Change by David Edelsohn :


--
nosy: +David.Edelsohn

___
Python tracker 

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

[issue44226] Threads shutting down in Py 2.7 but not in Py 3.69 while making SSH connection using Paramiko module

[Muralidhar BN]

New submission from Muralidhar BN :

Threads shutting down in Py 2.7 but not in Py 3.69 while making SSH connection 
using Paramiko module

Executing code qa-test-execute.py in Py 2.7 (Ubuntu 14.04.6 LTS)

Command 1 :
sudo python ./qa-test-execute.py

Output 1 :
2021-05-24 23:35:59,889[BaseCommandLine __init__ 139916740505872][DEBUG]: 
Attempt to close ssh-session within 10.0 seconds.
Exception AssertionError: 'attempt to release recursive lock not owned by 
thread' in > ignored

Command 2 :

sudo python ./qa-test-execute.py 2>&1 | tee 24052021_py27_execute_1.log

Output 2 :
2021-05-24 23:50:16,303[BaseCommandLine __init__ 139863250567440][DEBUG]: 
Attempt to close ssh-session within 10.0 seconds.
Exception AssertionError: 'attempt to release recursive lock not owned by 
thread' in > ignored


Executing code qa-test-execute.py in Py 3.69 (Ubuntu 18.04.5 LTS)

Command 1 :
sudo python ./qa-test-execute.py

Output 1 :
2021-05-24 23:53:49,293[BaseCommandLine __init__ 139973197423840][DEBUG]: 
Attempt to close ssh-session within 10.0 seconds.
2021-05-24 23:53:49,293[BaseCommandLine __init__ 139973197423840][DEBUG]: 
Closing internal ssh-client.
Fatal Python error: could not acquire lock for <_io.BufferedWriter 
name=''> at interpreter shutdown, possibly due to daemon threads

Command 2 :
sudo python3 ./qa-test-execute.py 2>&1 | tee 
launcher_gt20907_24052021_execute_py369_1.log

Output 2 : Terminal hangs & CTRL C to return prompt

2021-05-24 23:56:31,646[BaseCommandLine __init__ 140516619855072][DEBUG]: 
Attempt to close ssh-session within 10.0 seconds.
2021-05-24 23:56:31,646[BaseCommandLine __init__ 140516619855072][DEBUG]: 
Closing internal ssh-client.
^C


Behaviour of same code is different when executed in Py 2.7 & Py 3.69. 

Threads not terminating normally conflicting with paramiko / logging module  


qa-test-execute.py
#!/usr/bin/env python3

import sys
import traceback
import logging
import logging.config
import time
import threading
import multiprocessing
import paramiko



def lock_acquire_with_timeout1(lock, timeout_seconds):
"""
Try to acquire lock without specified timeout
@param lock: threading lock to be acquired
@type lock: threading.Lock
@param timeout_seconds: maximal time to make lock acquire attempts
@type timeout_seconds: float
"""
begin_time = time.time()
while time.time() - begin_time < timeout_seconds:
if lambda: lock.acquire(False):
return True
else:
time.sleep(1.0)
return None


def call_with_timeout1(method_to_call, timeout_seconds):
"""
Good for potentially "freeze" methods calls. Executes passed method in
separate thread. Waits for control returns within timeout. If timeout
exceed - return control to callee thread. Separate execution thread will
still be active.

@param method_to_call: method te be called
@type method_to_call: function
@param timeout_seconds: maximal time to wait for method call finished
@type timeout_seconds: float
"""
stop_thread = threading.Barrier(2)
thread_name = threading._newname("{}-%d".format(__name__))
call_thread = threading.Thread(target=method_to_call, name=thread_name)
call_thread.daemon = True 
call_thread.start()
print ("threading.activeCount() : %s",threading.activeCount())
print ("threading.currentThread() : %s", threading.currentThread())
print ("threading.enumerate() : %s", threading.enumerate() )
call_thread.join(timeout=timeout_seconds)
if call_thread.is_alive():
stop_thread.abort()
return not call_thread.is_alive()


def format_all_threads_stacks1():
"""
@return: formatted stacks for all running threads.
"""
stacktraces = []
for thread_id, stack in 
list(dict(list(sys._current_frames().items())).items()):
for thread1 in threading.enumerate():
if thread1.ident == thread_id:
stacktraces.append('Thread %s (daemon=%r) stacktrace: \n%s' %
   (thread1.name, thread1.daemon, 
''.join(traceback.format_stack(stack
else:
thread = None
return '\n'.join(stacktraces)


class SSHClient_noauth1(paramiko.SSHClient):

def _auth(self, username, *args):
self._transport.auth_none(username)
return

class BaseCommandLine1(object):

def __init__(self, connection_timeout=None):
self._connection_timeout = connection_timeout
self._connection_lock = multiprocessing.RLock()

self._ssh_client = None
self.logger = logging.getLogger('BaseCommandLine __init__ 
{}'.format(id(self)))
self.reset_connection1()

def __del__(self):
self.close1() 

def _wait_for_connection1(self):
begin_time = time.time()
self.logger.debug("Will attempt to connect with device for %s seconds." 
% self._connection_timeout)
while 

[issue42112] ZipFIle.write remove slash at the beginning of member's path

[Filipe Laíns]

Change by Filipe Laíns :


--
nosy: +FFY00

___
Python tracker 

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

[issue43066] Zipfile with leading slashes

[Filipe Laíns]

Change by Filipe Laíns :


--
nosy: +FFY00

___
Python tracker 

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

[issue29468] zipfile should catch ValueError as well as OSError to detect bad seek calls

[Filipe Laíns]

Filipe Laíns  added the comment:

That would not stay true to its meaning. AFAIK there are no implied exceptions 
in file objects. Given the meaning of ValueError, I'd say it is appropriate 
here.

--
nosy: +FFY00

___
Python tracker 

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

[issue42043] zipfile.Path should support inheritance

[Jason R. Coombs]

Change by Jason R. Coombs :


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

[issue42043] zipfile.Path should support inheritance

[Filipe Laíns]

Filipe Laíns  added the comment:

This can be closed now.

--
nosy: +FFY00

___
Python tracker 

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

f-strings and internationalisation.

[Antoon Pardon]

I have now come across several occasion where an author advice the use
of f-strings above the %-formatting and the format method. However it
seems these authors were only thinking about rather straight forward
english communication.

So what if you want your application to work with multiple languages.
Can that be done with f-strings?

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

[issue42654] Add folder for python customizations: __sitecustomize__

[Filipe Laíns]

Change by Filipe Laíns :


--
nosy: +FFY00

___
Python tracker 

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

[issue44192] Annotations, Inheritance and Circular Reference

[Filipe Laíns]

Filipe Laíns  added the comment:

s/holder/older/

Sorry, my dyslexia is acting up.

--

___
Python tracker 

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

[issue44192] Annotations, Inheritance and Circular Reference

[Filipe Laíns]

Filipe Laíns  added the comment:

The annotations will effectively become strings, instead of object references, 
in Python 3.11, which solves this issue.

You can enable this behavior in holder Python version with `from __future__ 
import annotations`, see PEP 563[1].

>>> class Base:
... _sub: list[Sub]
...
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in Base
NameError: name 'Sub' is not defined


>>> from __future__ import annotations
>>> class Base:
... _sub: list[Sub]
...
>>> class Sub:
... _parent: Base
...
>>>

[1] https://www.python.org/dev/peps/pep-0563/

--
nosy: +FFY00

___
Python tracker 

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

Re: learning python ...

[Alan Gauld via Python-list]

On 24/05/2021 07:21, hw wrote:

>> Inside the function f() the name 'x" shadows the global "x"; references
>> to "x" are to the function's local vairable. Which is very desireable.
> 
> If it works that way, I would consider it an entirely different 
> variable.  

Remember that in Python variables are just names.
They are literally keys to a dictionary and the value that is
associated with the name can change. It may be a literal value,
a function or a class or a type.

Names can be anything that is not a reserved word. (Provided
they keep within the naming grammar rules)

Also, unlike some other languages, type names are not reserved
words.

 by naming a variable like a variable type, I would think it is a bad
 idea for python to allow this without warning.

It does warn you, that's what the message it printed said:

 print(isinstance(int, float))
TypeError: isinstance() arg 2 must be a type or tuple of types


There is only on possible cause for that error. float is not
a type or a tuple of types. Therefore you must have changed
it somewhere.

Since this is the first place in the program that python can
identify an error, this is where the message gets printed.

You are working in a dynamic language that allows you to do
whatever you want to do.

-- 
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: Use Chrome's / Firefox's dev-tools in python

[max pothier]

Found this:
https://pastebin.com/fvLkSJRp
with use-select tags.
I'll try to use selenium and select the page.
But using the JSON packet that's sent will still be more practical.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael F. Stemper]

On 24/05/2021 09.32, Rob Cliffe wrote:


One day you may want to write (as you can in Python)

     class int(int):
         .

to shadow the built-in 'int' type with a modified version.  I'm not 
suggesting this has many real world applications, but it can be fun to 
play with.  Python has a "consenting adults" policy: it assumes that if 
you do something weird, you're doing it deliberately, and it doesn't try 
to stop you.  I am sure after a little more experience with Python you 
will remember the commonest built-in types (int, float, list, dict, str 


In my early days of writing python, I created lists named "list",
dictionaries named "dict", and strings named "str". I mostly know better
now, but sometimes still need to restrain my fingers.

--
Michael F. Stemper
Nostalgia just ain't what it used to be.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Use Chrome's / Firefox's dev-tools in python

[max pothier]

Ok,
So here's a screenshot:
https://ibb.co/2dtGr3c
1 is the website's scrollbar and 2 is Firefox's scrollbar.
Seems like it uses a strange embed thing.
The packet follows:
https://pastebin.com/2qEkhZMN
@Martin Di Paola: I sent you the pastebin password per email so that you're the 
only one who can access it, I just don't want anyone who passes by to be able 
to see my quotes...
What is that CSS tag? I could try to disable it in the inspector.

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

[issue44195] importlib.abc.TraversableReader is not implemented

[miss-islington]

miss-islington  added the comment:


New changeset ab4da079232356e781743b2782148bc7c03f1ee3 by Miss Islington (bot) 
in branch '3.9':
[3.9] bpo-44195: Use 'TraversableResources' in the docs to match the 
implementation. (GH-26317) (GH-26335)
https://github.com/python/cpython/commit/ab4da079232356e781743b2782148bc7c03f1ee3


--

___
Python tracker 

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

[issue44195] importlib.abc.TraversableReader is not implemented

[miss-islington]

miss-islington  added the comment:


New changeset d309bcc9e36adb2437a02550514df3efeb1b2343 by Miss Islington (bot) 
in branch '3.10':
bpo-44195: Use 'TraversableResources' in the docs to match the implementation. 
(GH-26317)
https://github.com/python/cpython/commit/d309bcc9e36adb2437a02550514df3efeb1b2343


--

___
Python tracker 

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

NumPy 1.21.0rc1 has been released.

[Charles R Harris]

Hi All,

On behalf of the NumPy team I am pleased to announce the release of NumPy
1.21.0rc1. The highlights are

- continued SIMD work covering more functions and platforms,
- initial work on the new dtype infrastructure and casting,
- improved documentation,
- improved annotations,
- the new ``PCG64DXSM`` bitgenerator for random numbers.

This NumPy release is the result of 561 merged pull requests contributed by
171 people. The Python versions supported for this release are 3.7-3.9,
support for Python 3.10 will be added after Python 3.10 is released. Wheels
can be downloaded from PyPI ; source
archives, release notes, and wheel hashes are available on Github
. Linux users will
need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014
wheels.

*Contributors*

A total of 171 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - @8bitmp3 +
   - @DWesl +
   - @Endolith
   - @Illviljan +
   - @Lbogula +
   - @Lisa +
   - @Patrick +
   - @Scian +
   - @h-vetinari +
   - @h6197627 +
   - @jbCodeHub +
   - @legoffant +
   - @sfolje0 +
   - @tautaus +
   - @yetanothercheer +
   - Abhay Raghuvanshi +
   - Adrian Price-Whelan +
   - Aerik Pawson +
   - Agbonze Osazuwa +
   - Aitik Gupta +
   - Al-Baraa El-Hag
   - Alex Henrie
   - Alexander Hunt +
   - Alizé Papp +
   - Allan Haldane
   - Amarnath1904 +
   - Amrit Krishnan +
   - Andras Deak
   - AngelGris +
   - Anne Archibald
   - Anthony Vo +
   - Antony Lee
   - Atharva-Vidwans +
   - Ayush Verma +
   - Bas van Beek
   - Bharat Raghunathan
   - Bhargav V +
   - Brian Soto
   - Carl Michal +
   - Charles Harris
   - Charles Stern +
   - Chiara Marmo +
   - Chris Barnes +
   - Chris Vavaliaris
   - Christina Hedges +
   - Christoph Gohlke
   - Christopher Dahlin +
   - Christos Efstathiou +
   - Chunlin Fang
   - Constanza Fierro +
   - Daniel Evans +
   - Daniel Montes +
   - Dario Mory +
   - David Carlier +
   - David Stansby
   - Deepyaman Datta +
   - Derek Homeier
   - Dong Keun Oh +
   - Dylan Cutler +
   - Eric Larson
   - Eric Wieser
   - Eva Jau +
   - Evgeni Burovski
   - FX Coudert +
   - Faris A Chugthai +
   - Filip Ter +
   - Filip Trojan +
   - François Le Lay +
   - Ganesh Kathiresan
   - Giannis Zapantis +
   - Giulio Procopio +
   - Greg Lucas +
   - Hollow Man +
   - Holly Corbett +
   - Inessa Pawson
   - Isabela Presedo-Floyd
   - Ismael Jimenez +
   - Isuru Fernando
   - Jakob Jakobson
   - James Gerity +
   - Jamie Macey +
   - Jasmin Classen +
   - Jody Klymak +
   - Joseph Fox-Rabinovitz
   - Jérome Eertmans +
   - Kamil Choudhury +
   - Kasia Leszek +
   - Keller Meier +
   - Kevin Sheppard
   - Kulin Seth +
   - Kumud Lakara +
   - Laura Kopf +
   - Laura Martens +
   - Leo Singer +
   - Leonardus Chen +
   - Lima Tango +
   - Lumir Balhar +
   - Maia Kaplan +
   - Mainak Debnath +
   - Marco Aurélio da Costa +
   - Marta Lemanczyk +
   - Marten van Kerkwijk
   - Mary Conley +
   - Marysia Winkels +
   - Mateusz Sokół +
   - Matt Haberland
   - Matt Hall +
   - Matt Ord +
   - Matthew Badin +
   - Matthias Bussonnier
   - Matthias Geier
   - Matti Picus
   - Matías Ríos +
   - Maxim Belkin +
   - Melissa Weber Mendonça
   - Meltem Eren Copur +
   - Michael Dubravski +
   - Michael Lamparski
   - Michal W. Tarnowski +
   - Michał Górny +
   - Mike Boyle +
   - Mike Toews
   - Misal Raj +
   - Mitchell Faas +
   - Mukulikaa Parhari +
   - Neil Girdhar +
   - Nicholas McKibben +
   - Nico Schlömer
   - Nicolas Hug +
   - Nilo Kruchelski +
   - Nirjas Jakilim +
   - Ohad Ravid +
   - Olivier Grisel
   - Pamphile ROY +
   - Panos Mavrogiorgos +
   - Patrick T. Komiske III +
   - Pearu Peterson
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Raúl Montón Pinillos +
   - Rin Arakaki +
   - Robert Kern
   - Rohit Sanjay
   - Roman Yurchak
   - Ronan Lamy
   - Ross Barnowski
   - Ryan C Cooper
   - Ryan Polley +
   - Ryan Soklaski
   - Sabrina Simao +
   - Sayed Adel
   - Sebastian Berg
   - Shen Zhou +
   - Stefan van der Walt
   - Sylwester Arabas +
   - Takanori Hirano
   - Tania Allard +
   - Thomas J. Fan +
   - Thomas Orgis +
   - Tim Hoffmann
   - Tomoki, Karatsu +
   - Tong Zou +
   - Touqir Sajed +
   - Tyler Reddy
   - Wansoo Kim
   - Warren Weckesser
   - Weh Andreas +
   - Yang Hau
   - Yashasvi Misra +
   - Zolboo Erdenebaatar +
   - Zolisa Bleki

Cheers,

Charles Harris
___
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

[issue44195] importlib.abc.TraversableReader is not implemented

[miss-islington]

Change by miss-islington :


--
pull_requests: +24927
pull_request: https://github.com/python/cpython/pull/26335

___
Python tracker 

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

[issue44195] importlib.abc.TraversableReader is not implemented

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +24926
pull_request: https://github.com/python/cpython/pull/26334

___
Python tracker 

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

[issue44195] importlib.abc.TraversableReader is not implemented

[Jason R. Coombs]

Jason R. Coombs  added the comment:

> are people supposed to be implementing readers with just files(), or are they 
> always expected to inherit TraversableResources?

A resource provider could potentially implement only the `files()` method (what 
I think you're calling `TraversableReader`), but my expectation was that all 
providers would provide a Reader derived from `TraversableResources` in order 
to provide backward-compatibility for the `ResourceReader` interface. Long 
term, I'd expect to deprecate all but `files()` on `TraversableResources`.

If a provider only implemented `files()` today and did not inherit from 
`TraversableResources`, they would still satisfy the `files()` API, but not the 
ResourceReader API (i.e. violate the expectation that 
`Loader.get_resource_reader` returns a ResourceReader).

I decided not to present both `TraversableReader` and `TraversableResources` as 
separate classes because the latter was sufficient for all known cases.

> It seems to me that maybe that is an issue and we actually want 
> [DegenerateFiles] to inherit from TraversableResources.

Perhaps. What advantage would that have?

> Regardless of the usefulness in code, please also consider type hinting.

Agreed, there are some places where type hints would drastically improve 
readability.

> If people are expecting to be using this protocol, we should expose it.

My instinct is `TraversableResources` is the preferred protocol for now, 
although I think it's likely we'll want to separate out the TraversableReader 
when necessary. Let's plan to do that in importlib_resources first.

--

___
Python tracker 

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

[issue42937] 192.0.0.8 (IPv4 dummy address) considered globally reachable

[Wayne Johnston]

Wayne Johnston  added the comment:

I completely agree with comments about .is_global and special_use.  Private IPs 
are just a subset of special use.  For some part Private means the Private use 
networks reserved by IANA and specified in IETF RFC1918.  

For this PR "IPv4 dummy address" is for sure not global.  Technically, it is 
not a private use IP either.  Just following what others have done.  I really 
like the apporoach of removing the routable special IPs.  Let me know if I 
should create a PR to do this.  This would include adding specific special use 
constant plus a whole bunch of very specific constants.  A constant like 
is_dummy will be added.

I pretty much have the code ready to go for IPV4.

--
components: +Library (Lib)
versions: +Python 3.11 -Python 3.9

___
Python tracker 

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

[issue40280] Consider supporting emscripten/webassembly as a build target

[Beuc]

Change by Beuc :


--
nosy:  -Beuc

___
Python tracker 

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

Re: learning python ...

[Rob Cliffe via Python-list]

Please don't be put off by your experience so far.  Everyone stumbles 
along the way and runs into "gotchas" when learning a new language.  
Python is a fantastic language for development.  One of my early 
"epiphany" moments was experimenting with different algorithms to try to 
find the right one for a tricky task.  If I remember rightly it took me 
about 2 weeks, on and off.  I could never have done it in any flavour of 
C in 6 months, or at all for that matter.  Python's built-in lists, 
dictionaries and memory management saved so much donkey work and made it 
so easy to throw ideas around!

Regards
Rob Cliffe

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

[issue44207] Add a version number to Python functions

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
nosy: +erlendaasland

___
Python tracker 

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

[issue44206] Add a version number to dict keys.

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
nosy: +erlendaasland

___
Python tracker 

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

[issue44206] Add a version number to dict keys.

[Mark Shannon]

Mark Shannon  added the comment:

http://theses.gla.ac.uk/2975/1/2011shannonphd.pdf page 128.

It means we don't need to cache a pointer to the keys, just the version number.
The version number is half the size (for 64 bit machines) and using it means 
that we don't leak keys.

--

___
Python tracker 

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

Re: learning python ...

[Michael Torrie]

On 5/24/21 8:42 AM, Schachner, Joseph wrote:
> OMG that is awful abuse of Python!  You have overloaded two Python
> keywords by making variables of that name.

Nitpick. hw did not overload keywords. Python does not allow keywords to
be overloaded.  Instead hw overwrote type names.  Upon learning that
type names are not keywords and can be overwritten, hw aw asked a
legitimate question: why does Python allow you to do that?  I don't
believe the OP found the answer acceptable, though.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Rob Cliffe via Python-list]

On 24/05/2021 14:34, hw wrote:


Your claim that I'm insulting python or anoyone is ridiculous. 
According to your logic, C is insulting python.  I suggest you stop 
making assumptions.
Calling a mature, widely used language "unfinished" because of what 
*you* see as a defect *is* insulting.
(Of course, all languages evolve, and Python is no exception.  But the 
change you are in effect proposing won't happen.)
And using a hectoring arrogant tone as a self-confessed Python beginner 
when addressing veterans with decades of experience in *developing 
Python* as well as developing with Python (disclosure: I'm not 
describing myself) is unlikely to endear anyone to your views.


Python has few keywords (deliberately so), and anything that is not a 
keyword can be used as an identifier.  That will stop your program from 
crashing in 5 years time if a new built-in type is added to the language 
that happens to have the same name as an identifier you used (like maybe 
'quaternion'  'matrix'  'group'  'query', to imagine a few).


One day you may want to write (as you can in Python)

    class int(int):
        .

to shadow the built-in 'int' type with a modified version.  I'm not 
suggesting this has many real world applications, but it can be fun to 
play with.  Python has a "consenting adults" policy: it assumes that if 
you do something weird, you're doing it deliberately, and it doesn't try 
to stop you.  I am sure after a little more experience with Python you 
will remember the commonest built-in types (int, float, list, dict, str 
etc.).


Regards
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list

[issue28806] Improve the netrc library

[Emmanuel Arias]

Emmanuel Arias  added the comment:

Hello everybody I've just make this PR 
https://github.com/python/cpython/pull/26330 to continue the work.

--

___
Python tracker 

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

[issue44207] Add a version number to Python functions

[Ken Jin]

Change by Ken Jin :


--
nosy: +kj

___
Python tracker 

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

[issue44206] Add a version number to dict keys.

[STINNER Victor]

STINNER Victor  added the comment:

I don't understand how such "key version" would be useful. Can you please 
elaborate?

--

___
Python tracker 

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

[issue44206] Add a version number to dict keys.

[Mark Shannon]

Change by Mark Shannon :


--
keywords: +patch
pull_requests: +24925
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/26333

___
Python tracker 

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

Re: learning python ...

[Michael Torrie]

On 5/24/21 8:37 AM, Chris Angelico wrote:
> We're talking about many different things. 

Indeed.

The context of that original question about whether this was shadowing
or not seemed to be specifically about the num=input(); num=int(num)
example that Cameron Simpson posted.  Although hw was not clear on that.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: learning python ...

[Schachner, Joseph]

OMG that is awful abuse of Python!  You have overloaded two Python keywords by 
making variables of that name.  As a result, float is no longer a type name, it 
is a variable name that refers to the value 6.67 !

Type(int) is int; type(float) is float, but isinstance(int,float) doesn't work 
because float is not a type in your script because you assigned float=6.67 and 
the local variable dictionary is searched first!

To fix this, make your variable name myfloat.   Change it wherever the variable 
name is wanted.  In particular, the last line should be 
print(isinstance(myfloat, float)).  The first argument is the variable, the 
second should be type name.

--- Joseph S.



Teledyne Confidential; Commercially Sensitive Business Data

-Original Message-
From: hw  
Sent: Sunday, May 23, 2021 3:34 PM
To: python-list@python.org
Subject: Re: learning python ...

On 5/23/21 7:28 PM, Peter Otten wrote:
> On 23/05/2021 06:37, hw wrote:
>>
>> Hi,
>>
>> I'm starting to learn python and have made a little example program 
>> following a tutorial[1] I'm attaching.
>>
>> Running it, I'm getting:
>>
>>
>> Traceback (most recent call last):
>>    File "[...]/hworld.py", line 18, in 
>>  print(isinstance(int, float))
>> TypeError: isinstance() arg 2 must be a type or tuple of types
>>
>>
>> I would understand to get an error message in line 5 but not in 18.  
>> Is this a bug or a feature?
> 
> It is a bug in your code (which you don't provide). Did you assign 
> some value to float, e. g.:
> 
>  >>> float = 42.0
>  >>> isinstance(int, float)
> Traceback (most recent call last):
>    File "", line 1, in 
>      isinstance(int, float)
> TypeError: isinstance() arg 2 must be a type or tuple of types
> 
> If you do not shadow the built-in you should get
> 
>  >>> isinstance(int, float)
> False
> 

Apparently the attachment was stripped from my message.  I'll put a smaller 
version directly into this message instead of an attachment:


#!/usr/bin/python

print("world!")

int = 17
print("world", int)

float = 6.670
print("world", float)

foo = 0
print(type(int))
print(type(float))
print(type(foo))

print(isinstance(foo, str))
print(isinstance(int, float))
print(isinstance(float, float))


I don't know about shadowing.  If I have defeated a whole variable type 
by naming a variable like a variable type, I would think it is a bad 
idea for python to allow this without warning.  It seems like a recipie 
for creating chaos.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael Torrie]

On 5/24/21 8:21 AM, Michael Torrie wrote:
> Given your posts thus far, hw, I don't think Python is a good fit for
> you. You're better off learning a language that more closely aligns with
> the statically-typed languages you already know.

That was unnecessarily harsh; my apologies.  I can see now that you
might be comparing some features to Perl, which is a more dynamic
language.  I see in your recent posts that you are trying to understand
how Python works, and that is good.  Hopefully you'll find Python a
dynamic and useful tool.  If not, that's perfectly okay. Use the right
tool for the job.
-- 
https://mail.python.org/mailman/listinfo/python-list