[issue39298] add BLAKE3 to hashlib

[Larry Hastings]

Larry Hastings  added the comment:

Jack O'Connor:
> Was any of the experimental C extension code [...] useful to you?
> I was wondering if it could be possible to copy blake3module.c from
> there verbatim.

I concede I didn't even look at it.  The glue code to mate the library with the 
CPython runtime wasn't the hard part.  And, Python has its own way of working 
(Argument Clinic etc).  I did what seemed easiest, which
was to start with CPython's BLAKE2 support and hack it up.  Given that
I had it working in maybe half a day, this seems reasonable.

I should take a peek at your experimental build though, just to confirm
I got the interfaces right.


> The setup.py build there also has working Windows and NEON support.

The CPython build process doesn't use setup.py to build extensions on
Windows.  I haven't looked recently, but back in the day they were
built like any other DLL, using its own "project file".  This will
require someone to use the MSVS GUI to create a new project, add files,
etc etc.  I assume they can just use the .asm files for the SIMD
extensions so hopefully this will be straightforward.

As for NEON support, the technique I used theoretically should Just Work.
I look forward to hearing back from someone building on ARM.  (I have
a cross-compiler setup for building for MiSTer, which is an ARM platform
with NEON support.  But the cross-compiler is a royal PITA to use...
it's a Docker image, and requires a bunch of manual configuration,
and I haven't touched any of that in more than a year.)


You seem to have done at least a partial code review of my PR, given
your comments to follow.  I appreciate it!  I tried to add you as a
"reviewer" but GitHub wouldn't permit it--I assume this is some sort
of permissions problem.  Still, it'd be nice if you were able to do
future code reviews using the GitHub review tool; are you permitted to
use that for my PR? 

> - My derive_key_context parameter requires a string and refuses to
> accept bytes. This is consistent with our Rust and C APIs (though the C
> API does include a _raw version specifically for bindings, which we're
> using here).

I was considering going the other way with it actually, requiring bytes.
Note that Python has first-class support for hard-coded bytes strings:

b = blake3.blake3(derive_key_context=b"My Funny Valentine (1984)")

The C interface takes "char *", not a "wchar_t *", and this seemed like
the most direct and relatable way to reflect that.  But I'm not militant
about this, and I'm willing to change the interface to require an actual
string (as in Unicode).  I note that your C API already dictates that
Unicode be encoded as UTF-8, so we can do that, and if the encoding fails
the user can deal with it.


> - I've included an `AUTO` constant that provides a special value (-1)
> for the `max_threads` argument, and I explicitly don't support
> `max_threads=0`.

I can do that too; again, I prefer the 0 there, but I'm not militant about
it.  However, it would make sense to me if you had that constant somewhere
in the BLAKE3 C .h files, which AFAICT you currently don't.


> - I enforce that the `data` arguments are positional-only and that the
> other keyword arguments are keyword-only. I think this is consistent
> with the rest of hashlib.

I suspect hashlib is mostly like that, due to being chock full of
legacy code.  But I don't see why that's necessary.  I think permitting
"data" to be a named argument is fine.  So unless you have a strong
conviction about it--which I bet you don't--I'll leave it as
positional-or-keyword.

There are rare circumstances where positional-only arguments are useful;
this isn't one of them.


> - I include a `.reset()` method.

I don't mind adding that.


> - Unrelated to tests: I haven't made any attempt to zero memory in my
> `dealloc` function. But if that's what other hashlib functions do,
> then I'm certainly in favor of doing it here too.

I inherited that from the BLAKE2 code I carved up to make the BLAKE3
version.  And yeah, it made sense to me, so I kept it.


Christian Heimes:
> GH-31686 is a massive patch set. I'm feeling uncomfortable adding
> such much new code for a new hashing algorithm. Did you ask the
> Steering Council for approval?

I didn't.  Like most hashing algorithms, BLAKE3 doesn't allocate
memory and doesn't perform any I/O.  All it does is meditate on
the data you pass in, and write to various pre-allocated fixed-size
buffers.  As large codebases go this seems pretty harmless, almost inert.

The Modules/_blake3/impl directory is about 32kloc.  I note that the
Modules/_blake2/impl directory you checked in in 2016 is about 21kloc,
and you didn't require Steering Council (or BDFL) approval for that.

As (former) Steering Council member Barry Warsaw says: JFDI!


> The platform detection and compiler flag logic must be added to
> configure.ac instead of setup.py. Erlend and I are in the process
> of making setup.py optional. I plan to remove it entirely along
> with 

[issue30556] asyncio.wait very slow with FIRST_COMPLETED

[Kumar Aditya]

Change by Kumar Aditya :


--
nosy: +asvetlov

___
Python tracker 

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

[issue36098] asyncio: ssl client-server with "slow" read

[Kumar Aditya]

Kumar Aditya  added the comment:

This has been fixed with bpo-44011 on main branch.

Output on main branch:

--
/workspaces/cpython/main.py:42: DeprecationWarning: There is no current event 
loop
  loop = asyncio.get_event_loop()
received 8192, total 8192
received 8192, total 16384
received 8192, total 24576
received 8192, total 32768
received 8192, total 40960
received 8192, total 49152
received 8192, total 57344
received 8192, total 65536
received 8192, total 73728
received 8192, total 81920
received 8192, total 90112
received 8192, total 98304
received 8192, total 106496
received 8192, total 114688
received 8192, total 122880
received 8192, total 131072
received 8192, total 139264
received 8192, total 147456
received 8192, total 155648
received 8192, total 163840
received 8192, total 172032
received 8192, total 180224
received 8192, total 188416
received 8192, total 196608
received 8192, total 204800
received 8192, total 212992
received 8192, total 221184
received 8192, total 229376
received 8192, total 237568
received 8192, total 245760
received 8192, total 253952
received 8192, total 262144
received 8192, total 270336
received 8192, total 278528
received 8192, total 286720
received 8192, total 294912
received 8192, total 303104
received 8192, total 311296
received 8192, total 319488
received 8192, total 327680
received 8192, total 335872
received 8192, total 344064
received 8192, total 352256
received 8192, total 360448
received 8192, total 368640
received 8192, total 376832
received 8192, total 385024
received 8192, total 393216
received 8192, total 401408
received 8192, total 409600
received 0, total 409600



This can be closed now @asvetlov.

--
nosy: +kumaraditya303

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Guido van Rossum]

Guido van Rossum  added the comment:

So if it doesn't work in mypy why bother making it work at runtime? Is there an 
actual use case that broke? (There might be, but probably esoteric if nobody's 
run into it until now.)

--

___
Python tracker 

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

[issue46925] Replace key if not identical to old key in dict

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I concur with Jelle and Methane that we can't do this without breaking code.

Also if you don't care about dict order, the work around is easy.  Just remove 
the old key:

d.pop(k); d[k] = v

--
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue45100] Improve help() by making typing.overload() information accessible at runtime

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

We could make my proposed overload registry more reusable by putting it in a 
different module, probably functools. (Another candidate is inspect, but 
inspect.py imports functools.py, so that would make it difficult to use the 
registry for functools.singledispatch.)

We could then bill it as a "variant registry", with an API like this:

def register_variant(key: str, variant: Callable) -> None: ...
def get_variants(key: str) -> list[Callable]: ...
def get_key_for_callable(callable: Callable) -> str | None: ...

@overload could then call register_variant() to register each overload, and 
code that wants a list of overloads (pydoc, inspect.signature, runtime type 
checkers) could call get_variants().

get_key_for_callable() essentially does 
f"{callable.__qualname__}.{callable.__name__}", but returns None for objects it 
can't handle. It will also support at least classmethods and staticmethods.

I will prepare a PR implementing this idea.

--

___
Python tracker 

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

[issue46925] Replace key if not identical to old key in dict

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

As @methane also said on the PR, this is a backward compatibility break and we 
can't just change the behavior. I'd be opposed to a change here: the proposed 
behavior isn't clearly better than the existing behavior (sometimes you want 
one behavior, sometimes another), and it will be difficult to find and adjust 
code that relies on the existing behavior.

--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

It doesn't really. If you do `x = New([1], (2, 3))` you get:

main.py:11: error: List item 0 has incompatible type "int"; expected "T"
main.py:11: error: Argument 2 to "New" has incompatible type "Tuple[int, int]"; 
expected "Tuple[T, T]"

https://mypy-play.net/?mypy=latest=3.10=a13c7a33c55a3aeee95324d46cd03ffd

--

___
Python tracker 

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Guido van Rossum]

Guido van Rossum  added the comment:

Mypy seems to allow this:

from typing import NamedTuple, TypeVar, Generic, List, Tuple

T = TypeVar("T")

class New(NamedTuple, Generic[T]):
x: List[T]
y: Tuple[T, T]

It's true that pyright doesn't, but maybe that's because it doesn't work in 
3.9-3.10?

--

___
Python tracker 

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

[issue24132] Direct sub-classing of pathlib.Path

[Barney Gale]

Change by Barney Gale :


--
pull_requests: +29812
pull_request: https://github.com/python/cpython/pull/31691

___
Python tracker 

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

[issue44136] Remove pathlib flavours

[Barney Gale]

Change by Barney Gale :


--
pull_requests: +29813
pull_request: https://github.com/python/cpython/pull/31691

___
Python tracker 

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

Re: How to solve the given problem?

[Dennis Lee Bieber]

On Fri, 4 Mar 2022 10:02:30 -0800 (PST), NArshad 
declaimed the following:

>You have made everything too complicated. Just adjust the units left in the 
>second feed into the third and fourth feed because the fish is special and 
>that's it.  The next day the second feed will be 100 units the way it used to 
>be.
>
My solution is generalized for 1) any number of periods in the day, 2)
mis-feed discovered at any point during the day, 3) works with any shape of
feeding schedule.

>What's wrong with the solution which I have written?

Nothing IF you can justify that it meets the documented requirements.
>From your original post:

"""
Implement some methods to distribute the remaining 40 unit in the rest of
the day and propose the new patterns. Try to keep the distribution similar
to the current feeding pattern. 
"""

Rephrased some, with emphasis, into what I see as the two major
requirements to be met:

*   distribute the remaining 40 unit IN THE REST OF THE DAY
*   TRY TO KEEP THE DISTRIBUTION SIMILAR TO THE CURRENT FEEDING PATTERN

"Remaining 40 unit" is really a noise clause resulting only from the
/example/ input schedule and feedings. Any programmatic solution should not
know, ahead of time, what the schedule was, nor what the feedings actually
were. There is no sense to writing a program in which all the input data is
hard-coded -- you might as well hard-code the output too, while you are at
it. I consider "..some methods" to also be noise clause -- the alternative
interpretation is that you are supposed to create multiple programs doing
different types of solutions to the one problem.

Assume, for example, that a fish#2 has a feeding schedule that looks
like:
150  100  20  20  20  20  20  20  100  150
(A big feed at start of day, an almost as large in second hour, six hours
at a constant 20, and then a large feed near the end, followed by a really
big feed to keep it happy overnight -- it seems to make more sense than
slowly starving the fish during the afternoon ).

That planned distribution could be called a bathtub curve -- high start
and ends with a flat middle. (as a sideways histogram)

***
**
**
**
**
**
**
**
**
***

Again, assume error in first two feeds as:

150  60

HOW DOES DUMPING THE 40 UNITS INTO HOUR 3 AND 4 SATISFY EITHER OF THE
REQUIREMENTS? (... rest of day, and similar distribution).

-=-=-=-
C:\Users\Wulfraed\Documents\_Hg-Repositories\REXX>rexx feedme.rex

Enter planned feeding schedule (feed units for each time period, space
separated)
150 100 20 20 20 20 20 20 100 150

Enter actual feeding schedule up to current feed period
150 60

PLAN:   10 time periods   620 total feed units
ACTUAL  :2 time periods   210 total feed units dispensed
MIS-FEED:  40 underfed

SCHEDULE: 150 60  |>   23 22 22 22 22 22
111166

C:\Users\Wulfraed\Documents\_Hg-Repositories\REXX>
-=-=-=-
(I modified the script to put |> at the point where the modified
feedings begin)

The result, as a histogram

***
**
**-
**.
**.
**.
**.
**.
***.
+
(Not very visible as each * is 10 units, and using . for 2.5, - for 5, +
for 7.5)


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Cameron Simpson]

On 03Mar2022 14:24, computermaster360  wrote:
>I want to make a little survey here.
>
>Do you find the for-else construct useful? Have you used it in
>practice? Do you even know how it works, or that there is such a thing
>in Python?

I used Python for years before understanding the for-else (and 
therefore, without seeing a use for it). Finally made the time to wrap 
my head around it quite recently and have used it a few times since.

It is a little niche, but when you want it, it is very nice indeed.  
Certainly avoids managing a special flag variable (which can be fiddly 
and therefore fragile) for "did my loop not run to completion"?

I sort of wish it had both "used break" and "did not use break" 
branches, a bit like try/except/else. But not very much.

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

[issue43923] Can't create generic NamedTuple as of py3.9

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

Was this ever documented to work? We have now disallowed this behavior in 3.9 
and 3.10 with few complaints, so it doesn't seem that important to restore it. 
Also, static type checkers generally disallow generic NamedTuples.

--

___
Python tracker 

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

[issue46798] xml.etree.ElementTree: get() doesn't return default value, always ATTLIST value

[Jacob Walls]

Jacob Walls  added the comment:

I agree not a bug. To ignore the document default you can set 
`specified_attributes` on the parser as documented:

https://docs.python.org/3/library/pyexpat.html#xml.parsers.expat.xmlparser.specified_attributes

Also, this was explicitly worked on recently in bpo-42151, so hard to imagine 
reversing course so soon. I suggest the issue be re-closed.

--
nosy: +jacobtylerwalls

___
Python tracker 

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

Re: Behavior of the for-else construct

[Peter J. Holzer]

On 2022-03-04 23:47:09 +, Avi Gross via Python-list wrote:
> I am not sure a reply is needed, Peter, and what you say is true. But
> as you point out, when using a German keyboard, I would  already have
> a way to enter symbols like ä, ö, ü and ß and no reason not to include
> them in variable names and so on if UNICODE is being used properly. I
> can use my last name in German notation as a variable in Python now:
> 
> Groß = 144
> Groß / 12
> 12.0

Yes, I'm using umlauts occasionally in variable names in Python, and
I've also used Greek characters and others.

But in Python I CAN use them. I DON'T HAVE to.

That's a big difference.

Characters like [] or {} are a part of Python's syntax. You can't avoid
using them. If you can't type them, you can't write Python. If it is
awkward to enter them (like having to type Alt-91 or pasting them from a
character table) it is painful to write programs.

German keyboards aquired an AltGr key and the ability to type these
characters in the mid to late 1980's. Presumably because those
characters were common in C and other programming languages and
programmers were complaining. I assume the same happened with keyboards
for other languages. These days you can assume that everybody can type
all ASCII characters (and knows how to do it).

But if you add arbitrary unicode characters to the syntax of your
language, for example using «» to delimit code blocks and ⦃ ⦄ for sets
and ∅ for None, then every programmer will have to figure out how to
enter those characters. And 90 % will probably say "Fuggedaboutit, I'm
not going to learn a new programming language I can't even type!"

hp


-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue46926] runpy.run_path didn't set __package__ to None as describe in doc

[Charlie Yan]

Change by Charlie Yan :


--
title: runpy.run_path didn't set __package__ as describe in doc -> 
runpy.run_path didn't set __package__ to None as describe in doc

___
Python tracker 

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

[issue46926] runpy.run_path didn't set __package__ as describe in doc

[Charlie Yan]

New submission from Charlie Yan :

As described in the doc: 
https://docs.python.org/3.8/library/runpy.html#runpy.run_path

> If the supplied path directly references a script file (whether as source or 
> as precompiled byte code), then __file__ will be set to the supplied path, 
> and __spec__, __cached__, __loader__ and __package__ will all be set to None.

But:
```
$ cat a.py
print(f'{__name__ = }')
print(f'{__package__ = }')

$ cat b.py
import runpy
runpy.run_path('a.py')

$ python3 b.py
__name__ = ''
__package__ = ''
```

`__package__` is not set to None as in the doc.

--
messages: 414555
nosy: yanhao.charles
priority: normal
severity: normal
status: open
title: runpy.run_path didn't set __package__ as describe in doc
versions: Python 3.8

___
Python tracker 

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

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

I am not sure a reply is needed, Peter, and what you say is true. But as you 
point out, when using a German keyboard, I would  already have a way to enter 
symbols like ä, ö, ü and ß and no reason not to include them in variable names 
and so on if UNICODE is being used properly. I can use my last name in German 
notation as a variable in Python now:

Groß = 144
Groß / 12
12.0

But even if I was German (and despite living in Austria for a year, I am not) I 
might want to write some things in French which might not be on that Keyboard, 
unless it includes everything in ISO 8859-1, albeit that standard is missing 
letters used rarely in some languages.

I have also used characters from Spanish and French and Hungarian and others as 
names in programs with no problems, albeit getting them in is not trivial on my 
very solid American English keyboard but can be done many ways. A fairly simple 
way is to use something like this using Google translate:

https://translate.google.com/?sl=de=en=translate

Pick the language you want and pop up a keyboard and type a bit and then 
copy/paste like this: גרוס

If I had to do this all the time, and occasionally I do, you can get other 
pop-up keyboards or helpers that take several keystrokes you memorize and 
convert it, ...

But it rarely is worth doing this if others will be using my code and 
complaining or trying to edit it. 

Chris has already pointed out the dangers of wandering too far from standard 
practice and making code hard for anyone else to deal with so yes, I would not 
rewrite key components or do something like make new function names that point 
to existing standard functions and only use the new (often not pronounceable) 
names. 


-Original Message-
From: Peter J. Holzer 
To: python-list@python.org
Sent: Fri, Mar 4, 2022 5:57 pm
Subject: Re: Behavior of the for-else construct

On 2022-03-04 00:38:22 +, Avi Gross via Python-list wrote:
> I have seen major struggles to get other character sets into
> languages. Any new language typically should have this built in from
> scratch and should consider adding non-ASCII characters into the mix.
> Mathematicians often use lots of weird braces/brackets as an example
> while normal programs are limited to [{( and maybe < and their
> counterparts. This leads to odd Python behavior (other languages too)
> where symbols are re-used ad nauseam. { can mean set or dictionary or
> simply some other way to group code.

I think the main reason for this is that people have to be able to type
the code. I do remember the days when German keyboards didn't have
brackets and braces and you had to type alt-123 to get a {. Made it real
fun to program in C ...

If you design a language and in IDE together (the way Smalltalk was
designed back in the 1970s or maybe Visual Basic) you can use all sorts
of funky characters because you can also provide a standard way to enter
them. But if you expect your users to type programs in a standard text
editor (even a fancy one like Emacs or Vim or VS Code), you have to
restrict yourself to a character set that most people can comfortably
type on their keyboards with the key mapping provided by their OS. Which
for historical reasons means US-ASCII.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | h...@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"


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

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

Re: Behavior of the for-else construct

[Chris Angelico]

On Sat, 5 Mar 2022 at 10:28, Peter J. Holzer  wrote:
>
> On 2022-03-04 11:34:07 +1100, Chris Angelico wrote:
> > On Fri, 4 Mar 2022 at 10:09, Avi Gross via Python-list
> >  wrote:
> > > The drumbeat I keep hearing is that some people hear/see the same
> > > word as implying something else. ELSE is ambiguous in the context it
> > > is used.
> >
> > What I'm hearing is that there are, broadly speaking, two types of
> > programmers [1]:
> >
> > 1) Those who think about "for-else" as a search tool and perfectly
> > understand how it behaves
> > 2) Those who have an incorrect idea about what for-else is supposed to
> > do, don't understand it, and don't like it.
>
> 3) Those who understand what it does und don't even find it*s syntax
> very confusing, yet only very rarely find it useful.
>
> I have probably used it a handful of times in 8 years of Python
> programming. Coincidentally, I think I used it just this week - but I
> can't find it any more which probably means that it was either in a
> throwaway script or I have since rewritten the code.
>

Part of group 1. It doesn't matter how often or rarely you use the
feature; there are a LOT of features of Python that I use only
occasionally, if ever. But as long as you know how to use it, it's
there when you need it.

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

Re: Behavior of the for-else construct

[Peter J. Holzer]

On 2022-03-04 11:34:07 +1100, Chris Angelico wrote:
> On Fri, 4 Mar 2022 at 10:09, Avi Gross via Python-list
>  wrote:
> > The drumbeat I keep hearing is that some people hear/see the same
> > word as implying something else. ELSE is ambiguous in the context it
> > is used.
> 
> What I'm hearing is that there are, broadly speaking, two types of
> programmers [1]:
> 
> 1) Those who think about "for-else" as a search tool and perfectly
> understand how it behaves
> 2) Those who have an incorrect idea about what for-else is supposed to
> do, don't understand it, and don't like it.

3) Those who understand what it does und don't even find it*s syntax
very confusing, yet only very rarely find it useful.

I have probably used it a handful of times in 8 years of Python
programming. Coincidentally, I think I used it just this week - but I
can't find it any more which probably means that it was either in a
throwaway script or I have since rewritten the code.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

Yes, Rob,

I keep wondering how many decades it will take before people here understand 
how I make a point with an example that is not intended in any way to be 
complete or the way I would do it.

No, I would not normally use the exception method, let alone in this case. This 
one practically screams for the method you suggest and iterate on a list of 
directories made from splitting the PATH variable. And, yes that method would 
likely use a for loop with a break if it is found and is a candidate for using 
the ELSE clause to note it has not been found.

But it is not an unusual idiom these days to use exceptions in places I never 
dreamed of in my earlier programming languages. A common example is always 
testing before accidentally dividing by zero and now code that depends on 
throwing the right exception and dealing with it, especially if the exception 
happens rarely.

So in situations where almost all programs are found in the first component of 
PATH, perhaps the exception approach is not horrible. It may even at times be 
done with less coding effort than other alternatives. Not my preferred way, of 
course.

-Original Message-
From: Rob Cliffe via Python-list 
To: python-list@python.org
Sent: Fri, Mar 4, 2022 5:22 pm
Subject: Re: Behavior of the for-else construct




On 04/03/2022 20:52, Avi Gross via Python-list wrote:
>
> I have an observation about exception handling in general. Some people use 
> exceptions, including ones they create and throw, for a similar idea. You 
> might for example try to use an exception if your first attempt fails that 
> specifies trying the next attempt. In my example of the PATH variable, you 
> might use something like calling a function and giving it what you are 
> looking for as well as a local copy of the PATH variable content and the 
> exception would be to call the function again with the first component of 
> PATH removed until you fail with an empty PATH. Yes, this is similar to just 
> having a recursive function.
That sounds neither readable nor efficient compared with using split() 
plus a loop.  Maybe you mean this to be a toy, unrealistic example?
> So the example tossed at us looks a bit more like this and it does run the 
> ELSE not because the loop is not done but because  the loop never calls a 
> break:
>
> for x in range(0):
>    print(x)
> else:
>    print("Finally finished!")
This would be more readable with a `zeroiterations` keyword, which 
accurately describes both the semantics and the intent.
> Which leads me right back to wondering why the sentinel approach is so bad!
>
>
It's not that bad, but it's more convenient and readable if it can be 
avoided.
Best wishes
Rob Cliffe

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

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

[issue46925] Replace key if not identical to old key in dict

[Malthe Borch]

New submission from Malthe Borch :

When a key that is equal to an existing key (but not the same object identity) 
is used to set a new value, the key itself is not replaced.

This manifests perhaps most clearly in `weakref.WeakKeyDictionary` where keys 
can mysteriously disappear.

Consider two equal keys, k1 and k2:

d = WeakKeyDictionary()
d[k1] = 1
d[k2] = 2
del k1

We would expect the dictionary to have a single entry k2 => 2. But in fact it 
is empty now.

--
components: Library (Lib)
messages: 414554
nosy: malthe
priority: normal
pull_requests: 29811
severity: normal
status: open
title: Replace key if not identical to old key in dict
type: behavior

___
Python tracker 

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

Re: Behavior of the for-else construct

[Peter J. Holzer]

On 2022-03-04 14:04:48 -0600, Om Joshi wrote:
> I'm not sure if anyone has mentioned it on this thread, but with
> respect to your comment about adding either on.empty or a decorator,
> the Django template syntax uses
> 
> {% for x in iterator %}
>  {{ x }}
> {% empty %}
>  Empty
> {% endfor %}
> 
> and this seems to work quite well and be incredibly intuitive, at
> least for Django html templates.

OTOH it is frequently not what you want.

Take this example from the Django docs:


{% for athlete in athlete_list %}
{{ athlete.name }}
{% empty %}
Sorry, no athletes in this list.
{% endfor %}


If athlete_list is empty, it will produce:


Sorry, no athletes in this list.


which is awful typography. You don't want a list with a single item, you
want that text *instead of* the list.

So you would have to write

{% if athlete_list %}

{% for athlete in athlete_list %}
{{ athlete.name }}
{% empty %}

{% else %}

Sorry, no athletes in this list.

{%endif %}

anyway.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Peter J. Holzer]

On 2022-03-04 08:38:52 -0600, Tim Chase wrote:
> On 2022-03-04 11:55, Chris Angelico wrote:
> > In MS-DOS, it was perfectly possible to have spaces in file names
> 
> DOS didn't allow space (0x20) in filenames unless you hacked it by
> hex-editing your filesystem (which I may have done a couple times).
> However it did allow you to use 0xFF in filenames which *appeared* as
> a space in most character-sets.

I may be misremembering (it's been 30+ years), but I seem to remember
that a simple fopen("with space.txt", "w") in Turbo C would create a
file with a space (actually called "WITH SPA.TXT", because upper case
only and 8+3).

It was a bad idea to do this, though, because there was no way to
manipulate such a file from command.com (You'd have to write another C
program).

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Peter J. Holzer]

On 2022-03-04 00:38:22 +, Avi Gross via Python-list wrote:
> I have seen major struggles to get other character sets into
> languages. Any new language typically should have this built in from
> scratch and should consider adding non-ASCII characters into the mix.
> Mathematicians often use lots of weird braces/brackets as an example
> while normal programs are limited to [{( and maybe < and their
> counterparts. This leads to odd Python behavior (other languages too)
> where symbols are re-used ad nauseam. { can mean set or dictionary or
> simply some other way to group code.

I think the main reason for this is that people have to be able to type
the code. I do remember the days when German keyboards didn't have
brackets and braces and you had to type alt-123 to get a {. Made it real
fun to program in C ...

If you design a language and in IDE together (the way Smalltalk was
designed back in the 1970s or maybe Visual Basic) you can use all sorts
of funky characters because you can also provide a standard way to enter
them. But if you expect your users to type programs in a standard text
editor (even a fancy one like Emacs or Vim or VS Code), you have to
restrict yourself to a character set that most people can comfortably
type on their keyboards with the key mapping provided by their OS. Which
for historical reasons means US-ASCII.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue46860] `--with-suffix` not respected on case-insensitive file systems

[Brett Cannon]

Change by Brett Cannon :


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

[issue46923] Implement stack overflow protection for supported platforms

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> Personally I'd prefer a new exception `StackOverflow` to `MemoryError`

+1 on a new exception (presumably a subclass of MemoryError).

How about using OverflowedStack instead?

The situation is not quite as bad as you suggest. Googling for "stack overflow" 
alone (with a space and no other qualifications):

* on Bing, scroll halfway down the first page of results to find the "People 
also ask..." 

  How do you get a stack overflow?
  How to prevent a stack overflow error?

* also on Bing at the bottom of the first page of results is a question on 
stackoverflow.com asking what causes memory stack overflows;

* on DuckDuckGo, the first page of search results fails to suggest anything 
useful;

* on Google itself, on the first page is the People Also Ask

  What causes stack overflows?

* as well as a link to Wikipedia's page on stack overflows.

I expect that going forward, "python stack overflow exception" will be 
sufficient to hit the Python docs somewhere on the first page.

Besides, presumably this OverflowedStack exception is likely to be rare, so I 
expect that few people will need to google it.

--
nosy: +steven.daprano

___
Python tracker 

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

Re: Behavior of the for-else construct

[Rob Cliffe via Python-list]

On 04/03/2022 20:52, Avi Gross via Python-list wrote:


I have an observation about exception handling in general. Some people use 
exceptions, including ones they create and throw, for a similar idea. You might 
for example try to use an exception if your first attempt fails that specifies 
trying the next attempt. In my example of the PATH variable, you might use 
something like calling a function and giving it what you are looking for as 
well as a local copy of the PATH variable content and the exception would be to 
call the function again with the first component of PATH removed until you fail 
with an empty PATH. Yes, this is similar to just having a recursive function.
That sounds neither readable nor efficient compared with using split() 
plus a loop.  Maybe you mean this to be a toy, unrealistic example?

So the example tossed at us looks a bit more like this and it does run the ELSE 
not because the loop is not done but because  the loop never calls a break:

for x in range(0):
   print(x)
else:
   print("Finally finished!")
This would be more readable with a `zeroiterations` keyword, which 
accurately describes both the semantics and the intent.

Which leads me right back to wondering why the sentinel approach is so bad!


It's not that bad, but it's more convenient and readable if it can be 
avoided.

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

[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work

[Philip Bloom]

Philip Bloom  added the comment:

> Do you mean just adding a note to the effect that SysLogHandler won't work on 
> macOS 12.2 because of changes to the syslog daemon on that platform?

Yes or removing the specific guidance about OSX handling on it, mostly just to 
reduce folks coming to ask as they transition to it.  That way it comes off 
that you need to provide a Syslog consumer to use the handler/not to expect one 
to exist on the platform.  Hope I'm phrasing that understandably.

--

___
Python tracker 

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

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

Om (unless your first name is Joshi),

Yes, your example captures some of my intent. I have not studied Django but 
your example suggests it uses special notation using a sort of set of braces 
like I have talked about "{%" and "%}" that allows freedom in using what might 
otherwise need keywords. Anything between braces can be an extension of the 
language in a context where users do not put their own variable names.

But again, any language defined can be set up to do things their own way. In 
Python, I believe the contents of a loop are not examined at all if skipped so 
searching in it for some clause of what to do if empty is not doable. The ELSE 
clause is a way to get the attention if there has been no break.

I would not be shocked if some language has a FOR command return a value such 
as the number of iterations if run and something like None if not and allows 
something like:

result = for ...

That might return 0 or None if it was part of the language but it is not.

Avi (my current first name)

-Original Message-
From: Om Joshi 
To: Avi Gross 
Cc: python-list 
Sent: Fri, Mar 4, 2022 3:04 pm
Subject: Re: Behavior of the for-else construct


I'm not sure if anyone has mentioned it on this thread, but with respect to 
your comment about adding either on.empty or a decorator, the Django template 
syntax uses

{% for x in iterator %}
 {{ x }}
{% empty %}
 Empty
{% endfor %}

and this seems to work quite well and be incredibly intuitive, at least for 
Django html templates. I took a look and it has other enhancements like a way 
to know when you are in the last iteration of the loop.

{% if forloop.last %}
...
{% endif %}

And also for the first item using forloop.first and a generalized counter in 
forloop.counter ..


  On Fri, 04 Mar 2022 13:45:21 -0600 Avi Gross via Python-list 
 wrote 
 > {NOTE, after some diversion, this long message does revert a bit to the 
 > topic.}
 > 
 > Ah, Chris, the games we played when we were young and relatively immature!
 > 
 > Has anyone else played with embedding "escape sequences" or other gimmicks 
 > in unexpected places like filenames so that on the right terminals, such as 
 > the VT100, it displayed oddly or was hard to open or delete as what showed 
 > was not quite the underlying representation?
 > 
 > The main reason for the restrictions in olden days was cost. Everything was 
 > so costly including storage/memory and CPU time. Clearly it is a lot easier 
 > to have fixed-length filenames that fit into say 16 bytes, or storing 
 > multiple flags about file permissions as single bits, even if it meant lots 
 > of bit-twiddling or using masks to retrieve their values. We think nothing 
 > of creating structures that have many others embedded in them as attributes 
 > or function calls that allow a hundred optional arguments so that the 
 > function spends much of the time used just figuring out what was set before 
 > doing whatever calculation is required to fulfill the request.
 > 
 > I was reading a novel recently (Jack Reacher Series) where the main 
 > character is noticing how much technology has changed as they have been 
 > ignoring it for a decade or so. Everything seems to be coming up faster. My 
 > view was that if something seems ten times as fast as it was, it also 
 > probably is doing a hundred or ten thousand times as much to get that 
 > result.  The real speed changes are often counterbalanced by expecting to do 
 > more. A web page served may display a screen of text but to transmit it may 
 > include not just lots of padding in the HTML, but have all kinds of code 
 > such as in Java or JavaScript or lots of back and forth with the server to 
 > keep something like a graph displayed being refreshed ...
 > 
 > So back to filenames, the concept of having to search for long filenames 
 > that may not even be stored sequentially in large blocks that can be read 
 > (ahead) efficiently, may have seemed to be so illogical as not to be 
 > considered. So given that the shorter ones were not allowed to have embedded 
 > spaces, it made sense to treat them like tokens that could be broken up at 
 > whitespace. As mentioned, languages (or other programs) would often parse a 
 > command line and create something like this for the main program in C with 
 > suitable version in Python and other languages:
 > 
 >    main(int argc, char *argv[])
 > 
 > The code variations on the above do suppose that something has already 
 > parsed the command line that invoked them and partitioned it properly into 
 > individual strings placed in an array of such strings and also returned how 
 > many arguments it saw. Users invoking the program needed to be careful such 
 > as using double quotes around anything with embedded spaces, where allowed.
 > 
 > But like many paradigms, there can be a shift. Consider the fact that 
 > languages like Python are constantly parsing things like names. Can you 
 > create a variable name like "me first" with 

Re: Getting Syslog working on OSX Monterey

[Peter J. Holzer]

On 2022-02-28 22:05:05 +, Barry Scott wrote:
> On 28 Feb 2022, at 21:41, Peter J. Holzer  wrote:
> > On 2022-02-27 22:16:54 +, Barry wrote:
> >> I have always assumed that if I want a logger syslog handler that I would 
> >> have
> >> to implement it myself. So far I have code that uses syslog directly and 
> >> have
> >> not written that code yet.
> > 
> > What do you mean by using syslog directly? The syslog(3) library
> > function also just sends messages to a "syslog listener" (more commonly
> > called a syslog daemon) - at least on any unix-like system I'm familiar
> > with (which doesn't include MacOS). It will, however, always use the
> > *local* syslog daemon - AFAIK there is no standard way to open a remote
> > connection (many syslog daemons can be configured to forward messages to
> > a remote server, however).
> 
> I'm re-reading the code to check on what I'm seeing. (Its been a long
> time since I last look deeply at this code).
> 
> You can write to /dev/log if you pass that to
> SysLogHandler(address='/dev/log'), but the default is to use a socket
> to talk to a network listener on localhost:514. There are no deamons
> listening on port 514 on my Fedora systems or mac OS.

If you are saying that SysLogHandler should use a system specific
default (e.g. "/dev/log" on Linux) instead of UDP port 514 everywhere, I
agree 99 % (the remaining 1 % is my contrarian alter ego arguing that
that's really the distribution maintainer's job since a Linux
distribution might use some other socket).

If you are saying it should use the libc syslog routines, I disagree for
at least two reasons: a) they are OS specific, b) you can't configure the
destination. So that would remove useful functionality.

In any case it seems strange to me that you want to rewrite it just to
avoid passing a single parameter to the constructor (or - more likely -
adding a single line to a config file).

> What you do not see used in the SyslogHandler() is the import syslog
> and hence its nor using openlog() etc from syslog API.

For good reasons. The C syslog API is missing important functionality.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue46896] add support for watching writes to selected dictionaries

[Carl Meyer]

Carl Meyer  added the comment:

Thanks for the feedback!

> Why so coarse?

Simplicity of implementation is a strong advantage, all else equal :) And the 
coarse version is a) at least somewhat proven as useful and usable already by 
Cinder / Cinder JIT, and b) clearly doable without introducing memory or 
noticeable CPU overhead to unwatched dicts. Do you have thoughts about how 
you'd do a more granular version without overhead?

> Getting a notification for every change of a global in module, is likely to 
> make use the use of global variables extremely expensive.

It's possible. We haven't ever observed this as an issue in practice, but we 
may have just not observed enough workloads with heavy writes to globals. I'd 
like to verify this problem with a real representative benchmark before making 
design decisions based on it, though. Calling a callback that is uninterested 
in a particular key doesn't need to be super-expensive if the callback is 
reasonably written, and this expense would occur only on the write path, for 
cases where the `global` keyword is used to rebind a global. I don't think it's 
common for idiomatic Python code to write to globals in perf-sensitive paths. 
Let's see how this shows up in pyperformance, if we try running it with all 
module globals dicts watched.

> For example, we could just tag the low bit of any pointer in a dictionary’s 
> values that we want to be notified of changes to

Would you want to tag the value, or the key? If value, does that mean if the 
value is changed it would revert to unwatched unless you explicitly watched the 
new value?

I'm a bit concerned about the performance overhead this would create for use of 
dicts outside the write path, e.g. the need to mask off the watch bit of 
returned value pointers on lookup.

> What happens if a watched dictionary is modified in a callback?

It may be best to document that this isn't supported; it shouldn't be necessary 
or advisable for the intended uses of dict watching. That said, I think it 
should work fine if the callback can handle re-entrancy and doesn't create 
infinite recursion. Otherwise, I think it's a case of "you broke it, you get to 
keep all the pieces."

> How do you plan to implement this? Steal a bit from `ma_version_tag`

We currently steal the low bit from the version tag in Cinder; my plan was to 
keep that approach.

> You'd probably need a PEP to replace PEP 509, but I think this may need a PEP 
> anyway.

I'd prefer to avoid coupling this to removal of the version tag. Then we get 
into issues of backward compatibility that this proposal otherwise avoids.

I don't think the current proposal is of a scope or level of user impact that 
should require a PEP, but I'm happy to write one if needed.

--

___
Python tracker 

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

Re: [python-uk] Fwd: It Will Never Work in Theory: live!

[MRAB]

On 2022-03-04 20:48, BELAHCENE Abdelkader wrote:

hi,
I receive a lot of email from the python-list, I want to disable it, when I
want to read the email, I want to go to he List.
Please How to disable  it.
Regards


This page explains how to unsubscribe:

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


Le jeu. 3 mars 2022 à 18:05, Steve Holden  a écrit :


A communication from my good friend Greg Wilsin (instigator of the
Software Carpentry workshops) which may be of use to some. It certainly
looks like great value for money.

Kind regards,
Steve


-- Forwarded message -
From: Greg Wilson 
Date: Tue, Mar 1, 2022 at 5:11 PM
Subject: It Will Never Work in Theory: live!
To: Steve Holden 


Hi Steve,

On April 27, It Will Never Work in Theory is running two sets of online
lightning talks from leading software engineering researchers in which
they’ll summarize actionable findings from their work for practitioners.
Tickets are now on sale at https://neverworkintheory.org/, and all money
raised will to go Books for Africa. I hope to see you there, and if you
could help spread the word or help sponsor it by matching money raised
from ticket sales, we'd be very grateful.

Cheers,

Greg

___
python-uk mailing list
python...@python.org
https://mail.python.org/mailman/listinfo/python-uk



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

Re: Behavior of the for-else construct

[Michael F. Stemper]

On 03/03/2022 19.54, Rob Cliffe wrote:

On 04/03/2022 01:44, Ethan Furman wrote:

On 3/3/22 5:32 PM, Rob Cliffe via Python-list wrote:

> There are three types of programmer: those that can count, and those that 
can't.

Actually, there are 10 types of programmer:  those that can count in binary, 
and those that can't.

1, 10, many.
No problem.


Ah, a George Gamow fan.

--
Michael F. Stemper
Psalm 82:3-4
--
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Chris Angelico]

On Sat, 5 Mar 2022 at 07:52, Avi Gross  wrote:
>
> Chris,
>
> My example was precisely what to do when it is an empty closet:

Does it correctly handle a closet with shirts in it, though?

There's not a lot of point demonstrating an alternate use for the
"else" clause when it is *absolutely identical* to simply placing two
loops one after another.

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

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

Chris,

My example was precisely what to do when it is an empty closet:

> closet = []
>
> attic = ["Costumes", "Sheets", "Shirts" ]
>
> for item in closet:
>     print(item)
>     if item == "Shirts" : print("FOUND in closet!!")
> else:
>     for item in attic:
>         print(item)
>         if item == "Shirts" : print("FOUND in attic!!")

Of course, for a more complete program, there is a reason to break out of 
either loop if you find what you are looking for. I was illustrating an 
alternate use in what I agree is a very incomplete example as it was meant only 
to illustrate one point.

And my example may be implemented very differently if you need to search in 
dozens of places. Consider the ubiquitous PATH variable. Many programs search 
in one after another of the components for something like a filename. Doing 
that with a series of nested FOR loops with each one nested in the ELSE of the 
previous one might be a tad ridiculous!

I have an observation about exception handling in general. Some people use 
exceptions, including ones they create and throw, for a similar idea. You might 
for example try to use an exception if your first attempt fails that specifies 
trying the next attempt. In my example of the PATH variable, you might use 
something like calling a function and giving it what you are looking for as 
well as a local copy of the PATH variable content and the exception would be to 
call the function again with the first component of PATH removed until you fail 
with an empty PATH. Yes, this is similar to just having a recursive function. 

But I am hoping to get across my view that there are many ways to do things but 
sometimes a new feature is useful because it is more direct or other reasons. 
in the case we are discussing, what are the scope issues in:

eye = 1
for eye in ... :
pass
else:
eye = None

It looks like all references to eye refer to the same object. Some other 
methods we have touched on (or others may bring up) may result in different 
results as variables may be in other name spaces. My understanding of the 
PYTHON-only implementation of the above is something like this. Imagine a FOR 
loop that does not ignore the contents no matter what and the body looks like:

if SOMETHING_IS_BEING_DONE:
   main code processing eye sequentially
else: # only used if nothing is being done normally
   eye = None

The above made-up scenario would allow the external ELSE to be seen as the 
implied else to an if that tests if the loop was actually entered. Of course it 
is not implemented this way, but it would show why variable eye is in the same 
scope in the several parts. Once you play with exceptions and other functions, 
this may change.

The alternative suggestions about ELSE being associated confuse this issue so I 
want to be clear.

The main meaning of the ELSE clause does not sound quite like this. It is 
actually about what to do with a loop that terminates normally, as I think 
Chris pointed out. This example finishes the loop normally and then does the 
ELSE:

for x in range(6):
  print(x)
else:
  print("Finally finished!")

The following example is similar but quits early:

for x in range(6):
  if x < 4: print(x)
  else: break
else:
  print("Finally finished!")

The (second) else clause is not run.

So the example tossed at us looks a bit more like this and it does run the ELSE 
not because the loop is not done but because  the loop never calls a break:

for x in range(0):
  print(x)
else:
  print("Finally finished!")

So unless I am missing something, the code would destroy the last value of the 
variable even in a valid case when it looks like:

for aye in range(0):
  pass
else:
  aye = None

I mean if you used range(5) you would expect the value of aye==4 after the 
loop. The above loop would leave it as aye==None which keeps it from being 
undefined. To decide if the loop ran at all would thus require further code 
such as:

if aye == None:
...

Which leads me right back to wondering why the sentinel approach is so bad!







-Original Message-
From: Chris Angelico 
To: python-list@python.org 
Sent: Fri, Mar 4, 2022 12:47 pm
Subject: Re: Behavior of the for-else construct


On Sat, 5 Mar 2022 at 03:44, Avi Gross via Python-list
 wrote:
>
> Dieter,
>
> Your use is creative albeit it is not "needed" since all it does is make sure 
> your variable is initialized to something, specifically None.
>
> So would this not do the same thing?
>
>   eye = None
>
>   for eye in range(0):
>       print(eye)
>
>   eye
>
> If I understand it, your example depends on a variable that is not yet 
> initialized to be used in a loop and retain the last value after the loop. 
> You then set it to None if it is not used as the loop is skipped. Others have 
> shown an example similar to the above of using a sentinel that lets you know 
> if the loop is skipped.
>
> Of course, there are some advantages in making it clear by doing it you way 
> that the loop (for example if 

Re: [python-uk] Fwd: It Will Never Work in Theory: live!

[BELAHCENE Abdelkader]

hi,
I receive a lot of email from the python-list, I want to disable it, when I
want to read the email, I want to go to he List.
Please How to disable  it.
Regards

Le jeu. 3 mars 2022 à 18:05, Steve Holden  a écrit :

> A communication from my good friend Greg Wilsin (instigator of the
> Software Carpentry workshops) which may be of use to some. It certainly
> looks like great value for money.
>
> Kind regards,
> Steve
>
>
> -- Forwarded message -
> From: Greg Wilson 
> Date: Tue, Mar 1, 2022 at 5:11 PM
> Subject: It Will Never Work in Theory: live!
> To: Steve Holden 
>
>
> Hi Steve,
>
> On April 27, It Will Never Work in Theory is running two sets of online
> lightning talks from leading software engineering researchers in which
> they’ll summarize actionable findings from their work for practitioners.
> Tickets are now on sale at https://neverworkintheory.org/, and all money
> raised will to go Books for Africa. I hope to see you there, and if you
> could help spread the word or help sponsor it by matching money raised
> from ticket sales, we'd be very grateful.
>
> Cheers,
>
> Greg
>
> ___
> python-uk mailing list
> python...@python.org
> https://mail.python.org/mailman/listinfo/python-uk
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38738] Fix formatting of True and False

[miss-islington]

miss-islington  added the comment:


New changeset fa69ec89393549a18944b3b92943709dac56a36a by Miss Islington (bot) 
in branch '3.10':
bpo-38738: Fix formatting of True and False in the threading documentation 
(GH-31678)
https://github.com/python/cpython/commit/fa69ec89393549a18944b3b92943709dac56a36a


--

___
Python tracker 

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

Re: Behavior of the for-else construct

[2QdxY4RzWzUUiLuE]

On 2022-03-04 at 11:14:29 -0500,
Dennis Lee Bieber  wrote:

>   Try to tell the difference between
> 
> afileand
> afile
> 
> when doing a directory listing.

Easy:  log in over a 110 baud modem, where the characters take almost as
much time as the beep.  ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38738] Fix formatting of True and False

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset 46a116c1c9f6b60a3d35ab9a419f8eee5de2542e by Géry Ogam in branch 
'main':
bpo-38738: Fix formatting of True and False in the threading documentation 
(GH-31678)
https://github.com/python/cpython/commit/46a116c1c9f6b60a3d35ab9a419f8eee5de2542e


--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue38738] Fix formatting of True and False

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue38738] Fix formatting of True and False

[Géry]

Change by Géry :


--
nosy: +maggyero
nosy_count: 4.0 -> 5.0
pull_requests: +29809
pull_request: https://github.com/python/cpython/pull/31678

___
Python tracker 

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

[issue45828] [sqlite3] use unraisable exceptions in callbacks

[Erlend E. Aasland]

Change by Erlend E. Aasland :


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

Re: Behavior of the for-else construct

[Om Joshi]

I'm not sure if anyone has mentioned it on this thread, but with respect to 
your comment about adding either on.empty or a decorator, the Django template 
syntax uses

{% for x in iterator %}
 {{ x }}
{% empty %}
 Empty
{% endfor %}

and this seems to work quite well and be incredibly intuitive, at least for 
Django html templates.

  On Fri, 04 Mar 2022 13:45:21 -0600 Avi Gross via Python-list 
 wrote 
 > {NOTE, after some diversion, this long message does revert a bit to the 
 > topic.}
 > 
 > Ah, Chris, the games we played when we were young and relatively immature!
 > 
 > Has anyone else played with embedding "escape sequences" or other gimmicks 
 > in unexpected places like filenames so that on the right terminals, such as 
 > the VT100, it displayed oddly or was hard to open or delete as what showed 
 > was not quite the underlying representation?
 > 
 > The main reason for the restrictions in olden days was cost. Everything was 
 > so costly including storage/memory and CPU time. Clearly it is a lot easier 
 > to have fixed-length filenames that fit into say 16 bytes, or storing 
 > multiple flags about file permissions as single bits, even if it meant lots 
 > of bit-twiddling or using masks to retrieve their values. We think nothing 
 > of creating structures that have many others embedded in them as attributes 
 > or function calls that allow a hundred optional arguments so that the 
 > function spends much of the time used just figuring out what was set before 
 > doing whatever calculation is required to fulfill the request.
 > 
 > I was reading a novel recently (Jack Reacher Series) where the main 
 > character is noticing how much technology has changed as they have been 
 > ignoring it for a decade or so. Everything seems to be coming up faster. My 
 > view was that if something seems ten times as fast as it was, it also 
 > probably is doing a hundred or ten thousand times as much to get that 
 > result.  The real speed changes are often counterbalanced by expecting to do 
 > more. A web page served may display a screen of text but to transmit it may 
 > include not just lots of padding in the HTML, but have all kinds of code 
 > such as in Java or JavaScript or lots of back and forth with the server to 
 > keep something like a graph displayed being refreshed ...
 > 
 > So back to filenames, the concept of having to search for long filenames 
 > that may not even be stored sequentially in large blocks that can be read 
 > (ahead) efficiently, may have seemed to be so illogical as not to be 
 > considered. So given that the shorter ones were not allowed to have embedded 
 > spaces, it made sense to treat them like tokens that could be broken up at 
 > whitespace. As mentioned, languages (or other programs) would often parse a 
 > command line and create something like this for the main program in C with 
 > suitable version in Python and other languages:
 > 
 >main(int argc, char *argv[])
 > 
 > The code variations on the above do suppose that something has already 
 > parsed the command line that invoked them and partitioned it properly into 
 > individual strings placed in an array of such strings and also returned how 
 > many arguments it saw. Users invoking the program needed to be careful such 
 > as using double quotes around anything with embedded spaces, where allowed.
 > 
 > But like many paradigms, there can be a shift. Consider the fact that 
 > languages like Python are constantly parsing things like names. Can you 
 > create a variable name like "me first" with an embedded space or even other 
 > symbols normally reserved such as parentheses? Most languages do not like 
 > such things. It makes it hard to parse if not quoted in some unique way. Yet 
 > languages like R happily allow such constructs if placed in back quotes 
 > (grave accents?) as in `me & you` as a variable name or the name of a 
 > function. Of course, you then never use the darn name without the extra 
 > quotes.
 > 
 > Similarly, when you make an object like a DataFrame, can you include spaces 
 > and other things in the names of columns (or sometimes rows)? If so, is 
 > there only access some ways and not others? 
 > 
 > The answer often is not simple. As Chris repeatedly highlights, making a 
 > language consistent as you play with features can be VERY hard and sometimes 
 > not quite possible without relaxing some rules or making exceptions. 
 > Sometimes the answer varies. In base R a data.frame can be given a column 
 > name like "me + you" which it then stores as "me...you" leading to odd 
 > results. But it happily returns that result if you ask for mydf$me using 
 > auto-completion. Spell it out fully and it won't find it! A later package 
 > added on makes modified data.frame objects called tibbles which do not 
 > autocomplete but do completely store and let you access the name so mydf$me 
 > fails and mydf$"me + you" or mydf
  On Fri, 04 Mar 2022 13:45:21 -0600 Avi Gross via 

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

{NOTE, after some diversion, this long message does revert a bit to the topic.}

Ah, Chris, the games we played when we were young and relatively immature!

Has anyone else played with embedding "escape sequences" or other gimmicks in 
unexpected places like filenames so that on the right terminals, such as the 
VT100, it displayed oddly or was hard to open or delete as what showed was not 
quite the underlying representation?

The main reason for the restrictions in olden days was cost. Everything was so 
costly including storage/memory and CPU time. Clearly it is a lot easier to 
have fixed-length filenames that fit into say 16 bytes, or storing multiple 
flags about file permissions as single bits, even if it meant lots of 
bit-twiddling or using masks to retrieve their values. We think nothing of 
creating structures that have many others embedded in them as attributes or 
function calls that allow a hundred optional arguments so that the function 
spends much of the time used just figuring out what was set before doing 
whatever calculation is required to fulfill the request.

I was reading a novel recently (Jack Reacher Series) where the main character 
is noticing how much technology has changed as they have been ignoring it for a 
decade or so. Everything seems to be coming up faster. My view was that if 
something seems ten times as fast as it was, it also probably is doing a 
hundred or ten thousand times as much to get that result.  The real speed 
changes are often counterbalanced by expecting to do more. A web page served 
may display a screen of text but to transmit it may include not just lots of 
padding in the HTML, but have all kinds of code such as in Java or JavaScript 
or lots of back and forth with the server to keep something like a graph 
displayed being refreshed ...

So back to filenames, the concept of having to search for long filenames that 
may not even be stored sequentially in large blocks that can be read (ahead) 
efficiently, may have seemed to be so illogical as not to be considered. So 
given that the shorter ones were not allowed to have embedded spaces, it made 
sense to treat them like tokens that could be broken up at whitespace. As 
mentioned, languages (or other programs) would often parse a command line and 
create something like this for the main program in C with suitable version in 
Python and other languages:

   main(int argc, char *argv[])

The code variations on the above do suppose that something has already parsed 
the command line that invoked them and partitioned it properly into individual 
strings placed in an array of such strings and also returned how many arguments 
it saw. Users invoking the program needed to be careful such as using double 
quotes around anything with embedded spaces, where allowed.

But like many paradigms, there can be a shift. Consider the fact that languages 
like Python are constantly parsing things like names. Can you create a variable 
name like "me first" with an embedded space or even other symbols normally 
reserved such as parentheses? Most languages do not like such things. It makes 
it hard to parse if not quoted in some unique way. Yet languages like R happily 
allow such constructs if placed in back quotes (grave accents?) as in `me & 
you` as a variable name or the name of a function. Of course, you then never 
use the darn name without the extra quotes.

Similarly, when you make an object like a DataFrame, can you include spaces and 
other things in the names of columns (or sometimes rows)? If so, is there only 
access some ways and not others? 

The answer often is not simple. As Chris repeatedly highlights, making a 
language consistent as you play with features can be VERY hard and sometimes 
not quite possible without relaxing some rules or making exceptions. Sometimes 
the answer varies. In base R a data.frame can be given a column name like "me + 
you" which it then stores as "me...you" leading to odd results. But it happily 
returns that result if you ask for mydf$me using auto-completion. Spell it out 
fully and it won't find it! A later package added on makes modified data.frame 
objects called tibbles which do not autocomplete but do completely store and 
let you access the name so mydf$me fails and mydf$"me + you" or mydf$`me + you` 
works but oddly an alternative format like mydf[, "me + you"] works while the 
similar mydf[, `me + you`] fails!

My point is not about R but a more general one. I can rant about many other 
languages, LOL! Allowing spaces or other characters in what used to be a more 
easily viewable name that can be parsed easier, can lead to having to find 
every place such things are used and seeing if they can be made to work 
consistently. I show an example above where it is not consistent, in my view. 

But when humans view things and their perceptions differ, you are inviting 
disagreements about whatever you implement. You may end up having to make 
people do more than they would 

[issue46924] make install hangs when installing zoneinfo/_zoneinfo.py

[AmericanEnglish]

New submission from AmericanEnglish :

I am currently trying to compile Python 3.10.2 from source. Everything seems to 
compile fine when doing a configure then a make. When I do make install though 
the install process hangs when compiling zoneinfo/_zoneinfo.py . Currently 
there are 6 python processes running when I view top. I have left this for 
several hours and the status is unchanged.

Here is the configure command I used:

export CXX=icpx
export CC=icx
# icx uses LLVM, so this is required for ctypes...?
export CFLAGS="-no-integrated-as"
# icx uses a clang frontend so these should be used as suggested by:
# https://devguide.python.org/setup/
export CFLAGS="$CFLAGS -Wno-unused-value -Wno-empty-body -Qunused-arguments"

cd $BUILD
../../302/configure \
--prefix $PREFIX \
--enable-profiling \
--enable-optimizations \
--with-ensurepip=install > configureOutput.txt


everything runs fine. When I CTRL+C to kill the make install it drops an error:
KeyboardInterrupt
  File "/installation/lib/python3.10/multiprocessing/synchronize.py", line 95, 
in __enter__
return self._semlock.__enter__()
  File "/installation/lib/python3.10/multiprocessing/process.py", line 315, in 
_bootstrap
self.run()
  File "/installation/lib/python3.10/multiprocessing/process.py", line 315, in 
_bootstrap
self.run()
  File "/installation/lib/python3.10/multiprocessing/queues.py", line 102, in 
get
with self._rlock:
  File "/installation/lib/python3.10/multiprocessing/process.py", line 108, in 
run
self._target(*self._args, **self._kwargs)
  File "/installation/lib/python3.10/multiprocessing/process.py", line 315, in 
_bootstrap
[interrupted]
make: [libinstall] Error 1 (ignored)


Any advice would be greatly appreciated. I have tried Googling the problem and 
searching StackOverflow and found no solutions that work.

I will say that this happens with AND without optimizations enabled.

--
components: Installation
messages: 414548
nosy: AmericanEnglish
priority: normal
severity: normal
status: open
title: make install hangs when installing zoneinfo/_zoneinfo.py
type: crash
versions: Python 3.10

___
Python tracker 

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

[issue46841] Inline bytecode caches

[Brandt Bucher]

Brandt Bucher  added the comment:


New changeset c4d2d57eefb1224a12e2e95e4508658dfbf6a7c9 by Brandt Bucher in 
branch 'main':
bpo-46841: Fix BINARY_OP's handling of inline caches (GH-31671)
https://github.com/python/cpython/commit/c4d2d57eefb1224a12e2e95e4508658dfbf6a7c9


--

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[Terry J. Reedy]

Change by Terry J. Reedy :


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

[issue25415] [io doc] Reword "there is no public constructor"

[miss-islington]

miss-islington  added the comment:


New changeset bdce1880365990403efdbeb60c4928c996370b0c by Miss Islington (bot) 
in branch '3.10':
bpo-25415: Remove confusing sentence from IOBase docstrings (PR-31631)
https://github.com/python/cpython/commit/bdce1880365990403efdbeb60c4928c996370b0c


--

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[miss-islington]

miss-islington  added the comment:


New changeset 01df048831eb631dfee41175f08d09b9ad1a9538 by Miss Islington (bot) 
in branch '3.9':
bpo-25415: Remove confusing sentence from IOBase docstrings (PR-31631)
https://github.com/python/cpython/commit/01df048831eb631dfee41175f08d09b9ad1a9538


--

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Christian Heimes]

Christian Heimes  added the comment:

GH-31686 is a massive patch set. I'm feeling uncomfortable adding such much new 
code for a new hashing algorithm. Did you ask the Steering Council for approval?

The platform detection and compiler flag logic must be added to configure.ac 
instead of setup.py. Erlend and I are in the process of making setup.py 
optional. I plan to remove it entirely along with distutils in 3.12.

--
assignee: christian.heimes -> 

___
Python tracker 

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

[issue29971] threading.Lock.acquire() not interruptible on Windows

[Géry]

Change by Géry :


--
nosy: +maggyero

___
Python tracker 

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

[issue45274] Race condition in Thread._wait_for_tstate_lock()

[Géry]

Change by Géry :


--
nosy: +maggyero

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Jack O'Connor]

Jack O'Connor  added the comment:

Thanks Larry! Was any of the experimental C extension code under 
https://github.com/oconnor663/blake3-py/tree/master/c_impl useful to you? I was 
wondering if it could be possible to copy blake3module.c from there verbatim. 
The setup.py build there also has working Windows and NEON support.

I've patched the blake3-py test suite (which both the production Rust-based 
extension and that experimental C-based extension currently pass) to invoke the 
new hashlib implementation from your branch. You can find the full test output, 
and the procedure I used to run the tests, in this Gist 
https://gist.github.com/oconnor663/533048580b1c0f4a01d1d55f57f92792. Here are 
some differences:

- My derive_key_context parameter requires a string and refuses to accept 
bytes. This is consistent with our Rust and C APIs (though the C API does 
include a _raw version specifically for bindings, which we're using here). For 
a long discussion of why we prefer to do things this way, see 
https://github.com/BLAKE3-team/BLAKE3/issues/13. The short version is that any 
use case that requires arbitrary bytes for the context string is almost 
certainly violating the documented security requirement that the context string 
must be hardcoded.

- I've included an `AUTO` constant that provides a special value (-1) for the 
`max_threads` argument, and I explicitly don't support `max_threads=0`.

- I enforce that the `data` arguments are positional-only and that the other 
keyword arguments are keyword-only. I think this is consistent with the rest of 
hashlib.

- I include a `.reset()` method. This isn't particularly useful in the default 
case, where you might as well create a new hasher. But when `max_threads` is 
greater than 1 in the Rust implementation, the hasher owns a thread pool, and 
`.reset()` is currently the only way to reuse that pool. (A BLAKE3 hasher is 
also ~2 KB, somewhat larger than other hashers, so callers who are pinching 
pennies with their allocator traffic might prefer to reuse the object.)

- Unrelated to tests: I haven't made any attempt to zero memory in my `dealloc` 
function. But if that's what other hashlib functions do, then I'm certainly in 
favor of doing it here too.

--

___
Python tracker 

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

[issue46922] tarfile.TarFile.next() crashes on empty tar files

[Ethan Furman]

Change by Ethan Furman :


--
nosy: +ethan.furman

___
Python tracker 

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

[issue17505] [doc] email.header.Header.__unicode__ does not decode header

[Vidhya]

Vidhya  added the comment:

@hniksic: Thanks for your suggestions. I will look into BytesFeedParser 
documents.
@david.murray: I can help you for the switch over to the default in the default 
policy and update the deprecation as well. It will be good if someone can guide 
me on this. Being a beginner, I am not sure if we are allowed to change the 
python code.

--

___
Python tracker 

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

Re: Behavior of the for-else construct

[Dennis Lee Bieber]

On Fri, 4 Mar 2022 08:38:52 -0600, Tim Chase
 declaimed the following:

>DOS didn't allow space (0x20) in filenames unless you hacked it by
>hex-editing your filesystem (which I may have done a couple times).
>However it did allow you to use 0xFF in filenames which *appeared* as
>a space in most character-sets.
>
>I may have caused a mild bit of consternation in school computer labs
>doing this. ;-)
>

Xerox CP/V actually allowed  to be embedded in file names...

Try to tell the difference between

afile  and
afile

when doing a directory listing.

{Though the BASIC interpreter gave it away -- doing a directory from within
the interpreter resulted in a hex representation of names with non-graphic
characters... In EBCDIC of course}


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43923] Can't create generic NamedTuple as of py3.9

[Guido van Rossum]

Guido van Rossum  added the comment:

Couldn't there be a subtler solution than rolling back GH-19371?

--

___
Python tracker 

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

Re: Behavior of the for-else construct

[Chris Angelico]

On Sat, 5 Mar 2022 at 03:44, Avi Gross via Python-list
 wrote:
>
> Dieter,
>
> Your use is creative albeit it is not "needed" since all it does is make sure 
> your variable is initialized to something, specifically None.
>
> So would this not do the same thing?
>
>   eye = None
>
>   for eye in range(0):
>   print(eye)
>
>   eye
>
> If I understand it, your example depends on a variable that is not yet 
> initialized to be used in a loop and retain the last value after the loop. 
> You then set it to None if it is not used as the loop is skipped. Others have 
> shown an example similar to the above of using a sentinel that lets you know 
> if the loop is skipped.
>
> Of course, there are some advantages in making it clear by doing it you way 
> that the loop (for example if copied and used elsewhere) needs to include the 
> else statement as an integral part.
>
> I would like to suggest a slight modification to the above as in if you are 
> searching for something in either seq1 and if not found in seq2. Call it 
> looking for your green shirt in the closet and if not found, looking in the 
> attic. Would this code make sense as such a use in several ways? In English, 
> look here first and if there is NOTHING there, look in the second place?
>
> closet = []
>
> attic = ["Costumes", "Sheets", "Shirts" ]
>
> for item in closet:
> print(item)
> if item == "Shirts" : print("FOUND in closet!!")
> else:
> for item in attic:
> print(item)
> if item == "Shirts" : print("FOUND in attic!!")
>
> Yes, as discussed, you could do an IF statement to check if closet is empty 
> but for iterators, it gets ...
>

Make sure you 'break' after finding it. Otherwise, you'll keep
searching the rest of your closet, and then still go on to search your
attic. The "else:" clause doesn't help you here unless that break is
present.

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

Re: Behavior of the for-else construct

[Chris Angelico]

 On Sat, 5 Mar 2022 at 02:02, Tim Chase  wrote:
>
> On 2022-03-04 11:55, Chris Angelico wrote:
> > In MS-DOS, it was perfectly possible to have spaces in file names
>
> DOS didn't allow space (0x20) in filenames unless you hacked it by
> hex-editing your filesystem (which I may have done a couple times).
> However it did allow you to use 0xFF in filenames which *appeared* as
> a space in most character-sets.

Hmm, I'm not sure which APIs worked which way, but I do believe that I
messed something up at one point and made a file with an included
space (not FF, an actual 20) in it. Maybe it's something to do with
the (ancient) FCB-based calls. It was tricky to get rid of that file,
though I think it turned out that it could be removed by globbing,
putting a question mark where the space was.

(Of course, internally, MS-DOS considered that the base name was
padded to eight with spaces, and the extension padded to three with
spaces, so "READ.ME" would be "READ\x20\x20\x20\x20ME\x20", but that
doesn't count, since anything that enumerates the contents of a
directory would translate that into the way humans think of it.)

> I may have caused a mild bit of consternation in school computer labs
> doing this. ;-)

Nice :)

> > Windows forbade a bunch of characters in file names
>
> Both DOS and Windows also had certain reserved filenames
>
> https://www.howtogeek.com/fyi/windows-10-still-wont-let-you-use-these-file-names-reserved-in-1974/
>
> that could cause issues if passed to programs.

Yup. All because, way back in the day, they didn't want to demand the
colon. If you actually *want* to use the printer device, for instance,
you could get a hard copy of a directory listing like this:

DIR >LPT1:

and it's perfectly clear that you don't want to create a file called
"LPT1", you want to send it to the printer. But noo it had to be
that you could just write "LPT1" and it would go to the printer.

> To this day, if you poke around on microsoft.com and change random
> bits of URLs to include one of those reserved filenames in the GET
> path, you'll often trigger a 5xx error rather than a 404 that you
> receive with random jibberish in the same place.
>
>   https://microsoft.com/…/asdfjkl → 404
>   https://microsoft.com/…/lpt1 → 5xx
>   https://microsoft.com/…/asdfjkl/some/path → 404
>   https://microsoft.com/…/lpt1/some/path → 5xx
>
> Just in case you aspire to stir up some trouble.
>

In theory, file system based URLs could be parsed such that, if you
ever hit one of those, it returns "Directory not found". In
practice... apparently they didn't do that.

As a side point, I've been increasingly avoiding any sort of system
whereby I take anything from the user and hand it to the file system.
The logic is usually more like:

If path matches "/static/%s":
1) Get a full directory listing of the declared static-files directory
2) Search that for the token given
3) If not found, return 404
4) Return the contents of the file, with cache markers

Since Windows will never return "lpt1" in that directory listing, I
would simply never find it, never even try to open it. This MIGHT be
an issue with something that accepts file *uploads*, but I've been
getting paranoid about those too, so, uhh... my file upload system now
creates URLs that look like this:

https://sikorsky.rosuav.com/static/upload-49497888-6bede802d13c8d2f7b92ca9fac7c

That was uploaded as "pie.gif" but stored on the file system as
~/stillebot/httpstatic/uploads/49497888-6bede802d13c8d2f7b92ca9fac7c
with some metadata stored elsewhere about the user-specified file
name. So hey, if you were to try to upload a file that had an NTFS
invalid character in it, I wouldn't even notice.

Maybe I'm *too* paranoid, but at least I don't have to worry about
file system attacks.

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

[issue46896] add support for watching writes to selected dictionaries

[Brandt Bucher]

Brandt Bucher  added the comment:

> Why so coarse?

> Getting a notification for every change of a global in module, is likely to 
> make use the use of global variables extremely expensive.

Perhaps a compromise is possible here: one global group/chain of callbacks 
registered for all dictionaries in an interpreter seems reasonable (to keep 
overhead low), but we could reduce the number of times it’s actually called by, 
say, tagging specific values of specific dictionaries to be watched.

For example, we could just tag the low bit of any pointer in a dictionary’s 
values that we want to be notified of changes to. Something like that seems 
like it could really keep the cost of watching down without sacrificing power.

--

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[miss-islington]

Change by miss-islington :


--
pull_requests: +29808
pull_request: https://github.com/python/cpython/pull/31689

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue25415] [io doc] Reword "there is no public constructor"

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset cedd2473a9bebe07f3ced4f341cf58a2fef07b03 by slateny in branch 
'main':
bpo-25415: Remove confusing sentence from IOBase docstrings (PR-31631)
https://github.com/python/cpython/commit/cedd2473a9bebe07f3ced4f341cf58a2fef07b03


--

___
Python tracker 

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

Re: Behavior of the for-else construct

[Dieter Maurer]

Avi Gross wrote at 2022-3-4 16:43 +:
>Your use is creative albeit it is not "needed" since all it does is make sure 
>your variable is initialized to something, specifically None.
>
>So would this not do the same thing?
>
>  eye = None
>
>  for eye in range(0):
>  print(eye)
>
>  eye

It would.

But, the `for` construct's main purpose is often to determine
a value for the loop variable and in this case, I like
that it itself can ensure that it gets a value.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue46923] Implement stack overflow protection for supported platforms

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue46923] Implement stack overflow protection for supported platforms

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue46389] 3.11: unused generator comprehensions cause f_lineno==None

[Mark Shannon]

Change by Mark Shannon :


--
stage: resolved -> 

___
Python tracker 

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

[issue46923] Implement stack overflow protection for supported platforms

[Mark Shannon]

New submission from Mark Shannon :

https://github.com/python/steering-council/issues/102 (definitely not PEP 651 
;))

We should implement efficient stack checks on those platforms that allow us to 
introspect stack extents.
Windows and posix systems allow us to do this.

C allows addresses of stack variables to be taken. This means that C stacks 
cannot be moved.
In theory they might be discontinuous, although I suspect that they are always 
contiguous.

My plan is to maintain a per-thread "safe region" of 32or 64k. We can check if 
the current stack pointer (or near enough) is in that region cheaply.
If we are not in that region, we can ask the O/S for a stack limit to determine 
a new "safe region". If we cannot find a safe region, then we raise a 
MemoryError.

Personally I'd prefer a new exception `StackOverflow` to `MemoryError` but, 
thanks to stackoverflow.com, it is now impossible for new programmers to do a 
web search to determine what a "stack overflow" is.
So, I guess MemoryError will have to do.

--
assignee: Mark.Shannon
messages: 414538
nosy: Mark.Shannon, gregory.p.smith
priority: normal
severity: normal
status: open
title: Implement stack overflow protection for supported platforms

___
Python tracker 

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

[issue44549] Update Windows installer to use bzip2 1.0.8

[Ned Deily]

Change by Ned Deily :


--
title: Update Windows installer to use BZip 1.0.8 -> Update Windows installer 
to use bzip2 1.0.8

___
Python tracker 

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

[issue44549] Update Windows installer to use BZip 1.0.8

[Ned Deily]

Change by Ned Deily :


--
assignee:  -> steve.dower
priority: normal -> critical
title: BZip 1.0.6 Critical Vulnerability -> Update Windows installer to use 
BZip 1.0.8
versions: +Python 3.10, Python 3.11

___
Python tracker 

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

[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

[sping]

sping  added the comment:

Hi mattip,

at the core the problem is not the use of non-URI character "}" for a namespace 
separator but the use of non-URI character "}" in a namespace URI.  
test_issue3151 is mistaken (meaning that non-URI characters in URIs are 
malformed XML) and the test has been removed in CPython pull request 
https://github.com/python/cpython/pull/31453/files .  Expat pull request 
https://github.com/libexpat/libexpat/pull/577 is related but it's about URI 
characters not about non-URI ones, so it does not change anything about 
test_issue3151 in PyPy.  Does that make sense?

Best, Sebastian

--

___
Python tracker 

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

[issue46922] tarfile.TarFile.next() crashes on empty tar files

[progval]

New submission from progval :

Hi,

I found two related bugs when calling tarfile.TarFile.next() on an empty tar 
file, both when trying to seek when it should not:

import io
import tarfile

# Create a tarball with no member:
fd = io.BytesIO()
with tarfile.open(fileobj=fd, mode="w") as tf:
pass

# read in stream mode:
fd.seek(0)
with tarfile.open(fileobj=fd, mode="r|") as tf:
print(tf.next())   # tarfile.StreamError: seeking backwards is not allowed

# read in normal mode:
fd.seek(0)
with tarfile.open(fileobj=fd, mode="r") as tf:
print(tf.next())  # ValueError: negative seek value -1

--
components: Library (Lib)
messages: 414536
nosy: progval
priority: normal
severity: normal
status: open
title: tarfile.TarFile.next() crashes on empty tar files
versions: Python 3.10, Python 3.9

___
Python tracker 

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

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

Dieter,

Your use is creative albeit it is not "needed" since all it does is make sure 
your variable is initialized to something, specifically None.

So would this not do the same thing?

  eye = None

  for eye in range(0):
  print(eye)

  eye

If I understand it, your example depends on a variable that is not yet 
initialized to be used in a loop and retain the last value after the loop. You 
then set it to None if it is not used as the loop is skipped. Others have shown 
an example similar to the above of using a sentinel that lets you know if the 
loop is skipped.

Of course, there are some advantages in making it clear by doing it you way 
that the loop (for example if copied and used elsewhere) needs to include the 
else statement as an integral part.

I would like to suggest a slight modification to the above as in if you are 
searching for something in either seq1 and if not found in seq2. Call it 
looking for your green shirt in the closet and if not found, looking in the 
attic. Would this code make sense as such a use in several ways? In English, 
look here first and if there is NOTHING there, look in the second place?

closet = []

attic = ["Costumes", "Sheets", "Shirts" ]

for item in closet:
print(item)
if item == "Shirts" : print("FOUND in closet!!")
else:
for item in attic:
print(item)
if item == "Shirts" : print("FOUND in attic!!")

Yes, as discussed, you could do an IF statement to check if closet is empty but 
for iterators, it gets ...







-Original Message-
From: Dieter Maurer 
To: Rob Cliffe 
Cc: python-list@python.org
Sent: Fri, Mar 4, 2022 2:12 am
Subject: Re: Behavior of the for-else construct


Rob Cliffe wrote at 2022-3-4 00:13 +:
>I find it so hard to remember what `for ... else` means that on the very
>few occasions I have used it, I ALWAYS put a comment alongside/below the
>`else` to remind myself (and anyone else unfortunate enough to read my
>code) what triggers it, e.g.
>
>     for item in search_list:
>         ...
>         ... break
>     else: # if no item in search_list matched the criteria
>
>You get the idea.
>If I really want to remember what this construct means, I remind myself
>that `else` here really means `no break`.  Would have been better if it
>had been spelt `nobreak` or similar in the first place.

One of my use cases for `for - else` does not involve a `break`:
the initialization of the loop variable when the sequence is empty.
It is demonstrated by the following transscript:

```pycon
>>> for i in range(0):
...   pass
...
>>> i
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'i' is not defined
>>> for i in range(0):
...   pass
... else: i = None
...
>>> i
>>>
```

For this use case, `else` is perfectly named.

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

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

[issue46921] Vectorcall support for super()

[Ken Jin]

Change by Ken Jin :


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

___
Python tracker 

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

[issue46921] Vectorcall support for super()

[Ken Jin]

New submission from Ken Jin :

This is related to bpo-46564. The changes are less ambitious but should produce 
a nice speedup.

--
messages: 414535
nosy: kj
priority: normal
severity: normal
status: open
title: Vectorcall support for super()
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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Dong-hee Na]

Dong-hee Na  added the comment:


New changeset d168c728f7114959e8fc147538ea1d24f2f5af79 by Dong-hee Na in branch 
'main':
bpo-46541: Remove usage of _Py_IDENTIFIER from lzma module (GH-31683)
https://github.com/python/cpython/commit/d168c728f7114959e8fc147538ea1d24f2f5af79


--

___
Python tracker 

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

[issue46919] After Python 3.9.2 is installed, the CVE-2019-12900 and CVE-2016-3189 vulnerabilities exist in Python39/DLLs/_bz2.pyd.

[Ned Deily]

Change by Ned Deily :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> BZip 1.0.6 Critical Vulnerability

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Larry Hastings]

Larry Hastings  added the comment:

Also, for what it's worth: I just ran my checksum benchmarker using a freshly 
built python a la my PR.  Here are my results when hashing 462183782 bytes 
(dicey-dungeons-linux64.zip):

  hash
 algorithm  timebytes/sec size hash 
 -  -- --  -
blake3  0.18976406 2435570699   64 0c72d0a07ba767b75b0c99fed38fda...
  sha1  0.21692419 2130623562   40 9fb83614394cd3b39e42b1d9f84a3c...
sha256  0.26399648 1750719480   64 2320129f2545ff8606d3db1d706d86...
sha224  0.28097475 1644929957   56 133b5da8d8b387f2bcfd69b0c73ed8...
   md4  0.34185237 1351998195   32 dea7585ea9fa4520687bab1dc671858e
   blake2b  0.53724666  860282275  128 e3653f33858a83b386c2fe865280a1...
   md5  0.58128106  795112407   32 299440e1968cf8f8abc288bac8c0a4fa
sha512_224  0.64589952  715566066   56 413d48b782f114870ef80815540678...
sha384  0.64645893  714946859   96 b1c1cd96cef79c15f2171b8aa81304...
sha512  0.65424513  706438241  128 e7d0cec3fe8b73d1534a7bdb484176...
sha512_256  0.68371638  675987586   64 3f58faba70cea4d6ea8a8371e71bbb...
  md5-sha1  0.80361958  575127576   72 299440e1968cf8f8abc288bac8c0a4...
 shake_128  0.84424524  547452041   64 c62a813897b81f67822fc07115deae...
   blake2s  0.85661793  539544839   64 cb8bd19c6ca446bbf7a8abbec61dc5...
  sha3_224  0.95759645  482649850   56 6f96d117c7fcbcd802b222854db644...
 shake_256  1.0152032   455262322   64 2d9f9dafe0ddf792c6407910946845...
  sha3_256  1.015744455019929   64 cc5d55fe0ac31f6e335da1bc6abaf3...
  sha3_384  1.3235858   349190644   96 13206910ff231fe51a38fe637ded30...
   sm3  1.4478934   319211203   64 021cd913540d95b13a03342b54f80d...
 ripemd160  1.4737549   313609670   40 1a956000b88267ec8fc23327d22548...
  sha3_512  1.9131832   241578418  128 e84b9f499b013956f6f36c93234ca3...

"time" is wall time in seconds.  So, yes, BLAKE3 was the fastest hash algorithm 
available on my machine--2.4GB/sec!

(I'm a little surprised by that result actually.  My CPU is pretty modern, so I 
assume it has the SHA1 extensions.  And I further assume we're using OpenSSL, 
and OpenSSL will use those extensions when available.  If BLAKE3 is *still* 
faster that OpenSSL, well! hats off to the BLAKE3 team.  And that just goes to 
show you how useful SIMD extensions are!)

--

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Larry Hastings]

Larry Hastings  added the comment:

Okay, so.  Here's a PR that adds BLAKE3 support to hashlib.

The code was straightforward; I just took the BLAKE2 module and modified it to 
only have one algorithm.  I also copied over the whole C directory tree from 
BLAKE3, which is totally okay fine by their license.  I didn't have to modify 
it a bit.

The tricky part was building it.  Building extension modules is done inside 
setup.py using distutils (or the modern replacement), and in order to get those 
sexy SIMD implementations I had to compile assembly-language files, or C files 
with extra flags.  What I did works great on my Linux box, and I have my 
fingers crossed that it'll work on other POSIX platforms.  I wrote a lng 
comment in setup.py explaining what I did and why.

Steve: I didn't do anything for Windows support.  Do you have time to take a 
pass at it?  Or if you know another core dev who does Windows build stuff, 
please nosy them.  Whoever does the work. I suggest you read 
https://github.com/BLAKE3-team/BLAKE3/blob/master/c/README.md for a little 
guidance on how to build BLAKE3 on Windows with SIMD support.  Also, I see you 
now build Python for Windows on ARM!  Does this mean Python can use BLAKE3's 
NEON support?  Maybe it's time to find out!  Get hyped!

Jack and I corresponded last year (or maybe 2020?) about what the API should 
look like.  The idea is, Jack also maintains a BLAKE3 Python extension on pypi, 
written in Rust.  Our goal was to make the two types behave identically, so 
that it could be like the old stringio / cstringio situation.  You can use the 
built-in one for convenience, but also you can install the Rust version from 
PyPI for even more performance.  Jack, it wouldn't hurt my feelings overly much 
if you checked my PR to make sure I got the interface right.

--

___
Python tracker 

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

[issue39298] add BLAKE3 to hashlib

[Larry Hastings]

Change by Larry Hastings :


--
pull_requests: +29805
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31686

___
Python tracker 

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

[issue46430] intern strings in deepfrozen modules

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests:  -29803

___
Python tracker 

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

[issue46541] Replace _Py_IDENTIFIER() with statically initialized objects.

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +29804
pull_request: https://github.com/python/cpython/pull/31683

___
Python tracker 

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

Re: Behavior of the for-else construct

[Tim Chase]

On 2022-03-04 11:55, Chris Angelico wrote:
> In MS-DOS, it was perfectly possible to have spaces in file names

DOS didn't allow space (0x20) in filenames unless you hacked it by
hex-editing your filesystem (which I may have done a couple times).
However it did allow you to use 0xFF in filenames which *appeared* as
a space in most character-sets.

I may have caused a mild bit of consternation in school computer labs
doing this. ;-)

> Windows forbade a bunch of characters in file names

Both DOS and Windows also had certain reserved filenames

https://www.howtogeek.com/fyi/windows-10-still-wont-let-you-use-these-file-names-reserved-in-1974/

that could cause issues if passed to programs.

To this day, if you poke around on microsoft.com and change random
bits of URLs to include one of those reserved filenames in the GET
path, you'll often trigger a 5xx error rather than a 404 that you
receive with random jibberish in the same place.

  https://microsoft.com/…/asdfjkl → 404
  https://microsoft.com/…/lpt1 → 5xx
  https://microsoft.com/…/asdfjkl/some/path → 404
  https://microsoft.com/…/lpt1/some/path → 5xx

Just in case you aspire to stir up some trouble.

-tkc




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

[issue46430] intern strings in deepfrozen modules

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +29803
pull_request: https://github.com/python/cpython/pull/31683

___
Python tracker 

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

[issue46896] add support for watching writes to selected dictionaries

[Mark Shannon]

Mark Shannon  added the comment:

Why so coarse?

Getting a notification for every change of a global in module, is likely to 
make use the use of global variables extremely expensive.

```
var = 0

CONST = 1
def foo(...):
...
```

I may well want to be notified if `foo` or `CONST` gets modified, but 
performance could suffer badly if we make a callback every time `var` is 
changed.

--

What happens if a watched dictionary is modified in a callback?

--

How do you plan to implement this? Steal a bit from `ma_version_tag` or replace 
`ma_version_tag`?
If you replace `ma_version_tag` this could actually speed things up a tad.

You'd probably need a PEP to replace PEP 509, but I think this may need a PEP 
anyway.

--

___
Python tracker 

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

[issue46311] Clean up PyLong_FromLong and PyLong_FromLongLong

[Mark Shannon]

Change by Mark Shannon :


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

[issue17505] [doc] email.header.Header.__unicode__ does not decode header

[R. David Murray]

R. David Murray  added the comment:

The policy is named 'default' because it was intended to become the default two 
feature releases after the new email code became non-provisional (first: 
deprecate not specifying an explicit policy, next release make default the 
default policy and make the deprecation only cover compat32).  However, for 
various reasons that switchover did not happen (one big factor being my reduced 
time spent doing python development).  It can happen any time someone steps 
forward to guide it through the release process.

--

___
Python tracker 

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

[issue31613] Localize tkinter.simpledialog.Default buttons as with file dialogs.

[Sampo Hippeläinen]

Sampo Hippeläinen  added the comment:

>Tk does not provide localized [Ok] and [Cancel] buttons.

This is not true. You can call ::msgcat::mc to localize core strings such as 
"OK" and "Cancel".

The full tk.call becomes

tk.call("namespace", "eval", "::tk", "::msgcat::mc", s)

to translate a string s, such as "OK".

I have made a custom modified version of simpledialog.py that makes use of this 
and indeed localizes the OK/Cancel buttons as they would be localized for tk 
messageboxes (which use Tcl/Tk Core localization). I submitted this now as a 
GitHub PR.

--
nosy: +sampo.hippelainen

___
Python tracker 

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

[issue31613] Localize tkinter.simpledialog.Default buttons as with file dialogs.

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +29801
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31682

___
Python tracker 

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

[issue46918] The vulnerability is included in /lib/python3.9/ensurepip after python 3.9.2 is installed.

[Ned Deily]

Ned Deily  added the comment:

To emphasize, Python 3.9.2 is obsolete and no longer supported; at the moment, 
the current release of Python 3.9 is 3.9.10. The most current bugfix release 
(3.9.x) obsoletes all previous releases of that Python version (3.9); during a 
version's support lifecycle, we only provide fixes for the most recent bugfix 
release (3.9.10). (Downstream third-party distributors of Python may have 
different support policies.)

https://www.python.org/downloads/

--
nosy: +ned.deily

___
Python tracker 

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

[issue5043] get_msvcr() returns None rather than []

[Alex Zunegin]

Alex Zunegin  added the comment:

This messes up building Cython extensions on MSYS2 and MINGW. Still here as of 
setuptools 60. 

There is no line 
```
return [] -
```
at the end. Adding it helps.

--
nosy: +gesserat

___
Python tracker 

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

[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

[mattip]

mattip  added the comment:

On PyPy, the test `test_issue3151` in `test_xml_etree.py` is failing with 
libexpat 2.4.6. I think the problem is connected to instantiation of the 
`XMLParser()` with `parser = expat.ParserCreate(encoding, "}")` where `"}"` is 
not a valid URI character. In any case, due to libexpat issue 577, 
https://github.com/libexpat/libexpat/pull/577 they will be releasing a new 
version 2.4.7 soon.

--
nosy: +mattip

___
Python tracker 

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

[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()

[Vincent FUNG]

Vincent FUNG  added the comment:

Thank you very much for your patient answer, I am still a developer who has 
just started, and it seems that I need to learn more about it.

I used repr().replace to replace with forward slashes, and also restricted 
paths ending in a slash to Improve reliability.

Thanks anagin. ;)

--

___
Python tracker 

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

virtualenv and make DESTDIR=

[Hartmut Goebel]

Hi,

How can I make installing a virtual environment honor DESTDIR? How can I 
install a virtual environment in $(DESTDIR)$(PREFIX), which behaves as 
being set-up in $(PREFIX)? (Of course, this virtual environment can not 
be used. My aim is to ship it as part of a rpm package)


In Makefiles is good practice to honor DESTDIR in the "install" target, 
like this


install:
    install -t $(DESTDIR)$(PREFIX)/bin build/bin/my-tool

Now when running

    python3 -m venv $(DESTDIR)$(PREFIX)

all paths in this virtual environment refer to $(DESTDIR)$(PREFIX) 
instead of just $$(PREFIX)


Any ideas?


Background:

More about DESTDIR: 
https://www.gnu.org/prep/standards/html_node/DESTDIR.html


Following Redhat's commendations, I want to install my (somewhat 
complex) software into /opt/my-software. To make it easier for users to 
use the software, my idea was to setup a virtual environment in 
/opt/my-software. Thus users can easily use /opt/my-software/bin/python 
and have the library provided by my-software available. My Software also 
includes some scripts, which will also reside in /opt/my-software/bin 
and refer to /opt/my-software/bin/python. This will avoid to require 
users to set up PYTHONPATH when thy want to use MY Software.



--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software 
Development


Goebel Consult, Landshut
http://www.goebel-consult.de

Blog: https://www.goe-con.de/blog/why-a-pki-is-barely-trustworthy
Kolumne: 
https://www.goe-con.de/hartmut-goebel/cissp-gefluester/2011-11-in-troja-nichts-neues 


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

[issue46841] Inline bytecode caches

[Mark Shannon]

Mark Shannon  added the comment:


New changeset 586b24d3be1aec5d2568b070a249b4d75e608782 by Brandt Bucher in 
branch 'main':
bpo-46841: Fix error message hacks in `GET_AWAITABLE` (GH-31664)
https://github.com/python/cpython/commit/586b24d3be1aec5d2568b070a249b4d75e608782


--

___
Python tracker 

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

[issue46781] Tracing: c_return doesn't report the result

[Mark Shannon]

Mark Shannon  added the comment:

This is an API change.

I agree that the API is not what it should be, but we can't change it without 
breaking an unknown amount of 3rd party code that uses it.

--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Unfortunately that's not how the parser works. I insist, for the compiler to 
raise the propper error the parser needs to succeed first. That would require 
us to modify the input string in arbitrary ways (many times we don't know 
exactly what went wrong) and recompile an arbitrary number of times.

I'm very sorry, but I will leave this issue closed as "won't fix" as the 
complexity of this solution is too much for the given benefit.

--

___
Python tracker 

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

[issue46920] Remove code made dead long ago with #if 0

[Oleg Iarygin]

Oleg Iarygin  added the comment:

Also forgot to add that git grep "#if 1" gives the following:

- added on 20 Nov 2014 by d600951: cpython/Python/pylifecycle.c:2427. "/* 
Disable this if you have trouble debugging bootstrap stuff */" - after seven 
years, no trouble was found so this always-true guard has no use.

--

___
Python tracker 

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