Re: Proposal: Disconnect comp.lang.python from python-list

[Richard Damon]

On 5/5/21 10:44 PM, Jon Ribbens via Python-list wrote:
> On 2021-05-06, Richard Damon  wrote:
>> On 5/5/21 9:40 PM, Jon Ribbens via Python-list wrote:
>>> On 2021-05-06, Paul Bryan  wrote:
 What's involved in moderating c.l.p? Would there be volunteers willing
 to do so?
>>> Nothing at all is involved, apart from changing the status of the group.
>>> The moderation would be done by the same people, in the same way, as the
>>> moderation of the list is done now. They wouldn't need to do any work
>>> they don't already do.
>> As someone with a long usenet background, converting the existing group
>> to moderated would be practically impossible. It just isn't done. It
>> would need to be a new group created with the .moderated tag. The
>> problem is that some servers won't change and getting things mixed like
>> that just creates propagation problems, so it just isn't done.
> As someone with a longer usenet background, it can be done, and there
> isn't any great reason not to do so in this case. But I did already
> suggest creating a new moderated group instead if people feel that's
> better.

Not so sure you are longer than me, I started on usenet is the late 80s
with dial up.

Yes, there have been a few successful conversions, but it is a lot of
work, and there may be too many servers that don't really care that
might get it wrong (google groups is one that could easily not care if
they break things, they have already broken comp.lang.c++

>
>> Basically, some machine would need to be designated to get all the
>> submissions to the group, emailed to it, and people would need to log
>> into the email account on that computer to approve all the posts, or a
>> robot could perhaps be setup to auto-approve most based on some rules.
> Are you unaware that the group is already gatewayed to a moderated
> mailing list for which all of that work is already done? The only
> difference is that currently that good work is then wasted and thrown
> away from the point of view of the group participants.

The big difference is that the mailing list directly gets its email from
the senders, and that was totally over SMTP so some From: verification
is possible, thus it make sense to let email addresses be validated for
whitelisting. Submissions from the moderated group have lost all
traceability to the original sender when it get forwarded via the NNTP
transportation link, so such a white list might not be as viable, and on
usenet many people intentionally post without valid From addresses, so a
LOT more messages will end up in the moderation queue, so more work for
the moderators.

-- 
Richard Damon

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

Programmed energy use

[Avi Gross via Python-list]

Benjamin,

The topic is being changed by me because I get amused by statistics.

We can all agree that any form of energy use uses energy, duh! But that does 
not make it good or bad in isolation.

If I had a job that had me wake up every day in the dark, drive for an hour to 
an airport, hop across the country (perhaps in a private plane) and drive a 
rental from there to work for another hour, find a few hours to do some work, 
then repeat and head home, that would indeed be wasteful as it happened several 
hundred times a year. If I opted to use a PC with ZOOM and a few other tools 
instead, including using resources in the cloud and especially programs running 
as PYTHON, would it be a net good thing for the environment?

The reality is the success of Python as an environment that is used in many 
servers, often alongside others, simply means it is used MORE. If no other 
language was ever used, it would get all the blame. If it was rarely used, it 
might hardly matter if it was efficient or not.

As it happens, I doubt it is anywhere as inefficient as some suggest. Some of 
the other alternatives arguably are much worse. Think how fast programs run 
that are written as humungous shell scripts that start a new full-process for 
each minor task, for example.

One potential set of solutions is fairly clear. Some programs, in ANY language, 
perform differently depending on which algorithms are used and many other such 
factors. So sure, a substantial number of programs of any type that are run 
frequently probably could be evaluated to make them more efficient. A dumb 
example is languages that allow you to keep adding entries to something like a 
vector or list or data.frame and do so by making a new data structure each time 
of one length longer and COPYING all the items over and then allowing the 
previous one to be garbage collected. Boy can that become expensive for longer 
input or calculations. But if you KNOW how many items you may need, you can 
reserve enough space in advance and fill it as you go along, or other such 
variants.

In my reality, many languages are now hybrids with some parts implemented using 
libraries already written carefully for efficiency and often in languages like 
C or C++ or FORTRAN or perhaps even lower-level languages that are 
machine-specific. Proper use of these routines gives a nice boost.

And, sure, if you run some programs that never use many language features on a 
server, I suspect you could make a customized version of something like Python 
built that does not incorporate much of what will never be used so the core 
loaded is smaller and perhaps in many ways faster. I know that has been done 
for example for some smaller processors.

Having said all that, if someone really made a truly compliant improvement on 
python that ran everything and was compatible with future additions, great. 
Would it be public domain and open-code? Would it be handed over to the groups 
currently responsible for python so parts or the whole could be used if people 
were interested? Would it be maintained? Free? ...

My impression from the past is that what is being offered will NOT be a python 
interpreter at all but rather a file or files that define the language and an 
engine that takes programs in any language that has been defined that way and 
combining the two to compile some kind of executable. Some of that has sort of 
been done, albeit just for one language at a time. Adding features to the 
language though, or even fixing any errors, might become a bit weirder.

But none of this really has to do with the environment really. The goal for 
many people is to make our computing CHEAPER and more reliable and so on. 
Obviously faster processors or peripherals may deliver more bang for the buck 
and reducing the heat generated or energy used (somewhat related) are other 
such facets. But if we improved our computers (including software like python) 
and simply found lots more uses for them so we kept adding more farms of 
servers such as to mine new bitcoin or whatever, we would not have progress.

Heck, we can cut back on wasting energy by not allowing children to play video 
games or look at social media for more than an hour a day and limit people from 
getting their email more than once a day like in the old days! For adults, we 
could remove most pornography which apparently is one of the biggest uses for 
the internet.

Does anyone have even a guess on what globally is contributing most to such 
energy usage even within the computer realm? I mean can we blame Apple and 
Microsoft and Google and such for their operating systems which run all the 
time and often consume all available CPU when nothing else is happening and it 
just keeps looking for something to do? How much time is spent by SQL queries 
whether called from python or any other languages, or google searches that may 
trigger a parallel search in thousands or more places then telling us the first 
10, plus 

Re: Bloody rubbish

[Joe Pfeiffer]

Mr Flibble  writes:

> Python is slow and significant whitespace is patently absurd.

Why am I not surprised to learn your "fast" implementation turns out to
be something other than python?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposal: Disconnect comp.lang.python from python-list

[Jon Ribbens via Python-list]

On 2021-05-06, Richard Damon  wrote:
> On 5/5/21 9:40 PM, Jon Ribbens via Python-list wrote:
>> On 2021-05-06, Paul Bryan  wrote:
>>> What's involved in moderating c.l.p? Would there be volunteers willing
>>> to do so?
>> Nothing at all is involved, apart from changing the status of the group.
>> The moderation would be done by the same people, in the same way, as the
>> moderation of the list is done now. They wouldn't need to do any work
>> they don't already do.
>
> As someone with a long usenet background, converting the existing group
> to moderated would be practically impossible. It just isn't done. It
> would need to be a new group created with the .moderated tag. The
> problem is that some servers won't change and getting things mixed like
> that just creates propagation problems, so it just isn't done.

As someone with a longer usenet background, it can be done, and there
isn't any great reason not to do so in this case. But I did already
suggest creating a new moderated group instead if people feel that's
better.

> Basically, some machine would need to be designated to get all the
> submissions to the group, emailed to it, and people would need to log
> into the email account on that computer to approve all the posts, or a
> robot could perhaps be setup to auto-approve most based on some rules.

Are you unaware that the group is already gatewayed to a moderated
mailing list for which all of that work is already done? The only
difference is that currently that good work is then wasted and thrown
away from the point of view of the group participants.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposal: Disconnect comp.lang.python from python-list

[Richard Damon]

On 5/5/21 9:40 PM, Jon Ribbens via Python-list wrote:
> On 2021-05-06, Paul Bryan  wrote:
>> What's involved in moderating c.l.p? Would there be volunteers willing
>> to do so?
> Nothing at all is involved, apart from changing the status of the group.
> The moderation would be done by the same people, in the same way, as the
> moderation of the list is done now. They wouldn't need to do any work
> they don't already do.

As someone with a long usenet background, converting the existing group
to moderated would be practically impossible. It just isn't done. It
would need to be a new group created with the .moderated tag. The
problem is that some servers won't change and getting things mixed like
that just creates propagation problems, so it just isn't done.

Basically, some machine would need to be designated to get all the
submissions to the group, emailed to it, and people would need to log
into the email account on that computer to approve all the posts, or a
robot could perhaps be setup to auto-approve most based on some rules.

-- 
Richard Damon

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

RE: neoPython : Fastest Python Implementation: Coming Soon

[Avi Gross via Python-list]

Chris,

I got the fastest python yesterday as it was so fast that it beat the one
coming tomorrow.

The trick is adding back the legs that evolution allowed to lapse.

Without bated breath,

Regardless,

Avi

-Original Message-
From: Python-list  On
Behalf Of Chris Angelico
Sent: Wednesday, May 5, 2021 12:02 PM
To: Python 
Subject: Re: neoPython : Fastest Python Implementation: Coming Soon

On Thu, May 6, 2021 at 2:01 AM Mr Flibble
 wrote:
>
> neoPython : Fastest Python Implementation: Coming Soon
>
> Message ends.
>
> /Flibble
>

My breath: not being held.

Message ends.

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

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

Re: Proposal: Disconnect comp.lang.python from python-list

[Jon Ribbens via Python-list]

On 2021-05-06, Paul Bryan  wrote:
> What's involved in moderating c.l.p? Would there be volunteers willing
> to do so?

Nothing at all is involved, apart from changing the status of the group.
The moderation would be done by the same people, in the same way, as the
moderation of the list is done now. They wouldn't need to do any work
they don't already do.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposal: Disconnect comp.lang.python from python-list

[Paul Bryan]

What's involved in moderating c.l.p? Would there be volunteers willing
to do so?

On Thu, 2021-05-06 at 00:43 +, Jon Ribbens via Python-list wrote:
> On 2021-05-06, Chris Angelico  wrote:
> > On Thu, May 6, 2021 at 10:32 AM Paul Bryan  wrote:
> > > 
> > > Given the ease of spoofing sender addresses, and its propensity
> > > for use
> > > in anonymous spamming and trolling (thanks python-list-owner for
> > > staying on top of that!), I propose to disconnect
> > > comp.lang.python from
> > > the python-list mailing list. Both would then operate
> > > independently.
> > > 
> > 
> > As someone who exclusively follows the mailing list, I selfishly
> > want
> > to support this, as it would notably improve the signal-to-noise
> > ratio. But I'm aware that there are a number of good people who
> > currently use the newsgroup, and those people would then be
> > abandoned
> > in the cess-pool.
> 
> Counter-proposal that I have suggested several times before that
> would
> solve both these problems: make the newsgroup moderated.
> 
> (Or, I suppose, create comp.lang.python.moderated and gateway it
> to the mailing list, and disconnect comp.lang.python from the list.)

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

Re: Proposal: Disconnect comp.lang.python from python-list

[Chris Angelico]

On Thu, May 6, 2021 at 10:43 AM Avi Gross via Python-list
 wrote:
>
> Chris,
>
> Given some notice, what stops anyone from joining the mailing list before
> there is a divorce between the forums?

Nothing! Nothing at all. That is, if you're talking about *people*.
People are absolutely welcome to join. The reason the S/N would
improve is all the non-people who post to the newsgroup.

But there are some people who simply don't want to use the mailing
list, and that's currently a fully-welcomed option. I won't name
names, but there definitely are people who would prefer a newsreader,
so the gateway is serving them very well.

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

Re: Proposal: Disconnect comp.lang.python from python-list

[Jon Ribbens via Python-list]

On 2021-05-06, Chris Angelico  wrote:
> On Thu, May 6, 2021 at 10:32 AM Paul Bryan  wrote:
>>
>> Given the ease of spoofing sender addresses, and its propensity for use
>> in anonymous spamming and trolling (thanks python-list-owner for
>> staying on top of that!), I propose to disconnect comp.lang.python from
>> the python-list mailing list. Both would then operate independently.
>>
>
> As someone who exclusively follows the mailing list, I selfishly want
> to support this, as it would notably improve the signal-to-noise
> ratio. But I'm aware that there are a number of good people who
> currently use the newsgroup, and those people would then be abandoned
> in the cess-pool.

Counter-proposal that I have suggested several times before that would
solve both these problems: make the newsgroup moderated.

(Or, I suppose, create comp.lang.python.moderated and gateway it
to the mailing list, and disconnect comp.lang.python from the list.)
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Proposal: Disconnect comp.lang.python from python-list

[Avi Gross via Python-list]

Chris,

Given some notice, what stops anyone from joining the mailing list before
there is a divorce between the forums?

Everybody has trivial access to an email account these days and many mailers
allow incoming messages that fit a pattern to be placed in some names folder
to be read as a group if one wishes.

The difference would include less spoofing but also the ability to remove
and that are causing annoyance here.

Avi

-Original Message-
From: Python-list  On
Behalf Of Chris Angelico
Sent: Wednesday, May 5, 2021 8:37 PM
To: Python 
Subject: Re: Proposal: Disconnect comp.lang.python from python-list

On Thu, May 6, 2021 at 10:32 AM Paul Bryan  wrote:
>
> Given the ease of spoofing sender addresses, and its propensity for 
> use in anonymous spamming and trolling (thanks python-list-owner for 
> staying on top of that!), I propose to disconnect comp.lang.python 
> from the python-list mailing list. Both would then operate independently.
>

As someone who exclusively follows the mailing list, I selfishly want to
support this, as it would notably improve the signal-to-noise ratio. But I'm
aware that there are a number of good people who currently use the
newsgroup, and those people would then be abandoned in the cess-pool.

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

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

Re: Proposal: Disconnect comp.lang.python from python-list

[Chris Angelico]

On Thu, May 6, 2021 at 10:32 AM Paul Bryan  wrote:
>
> Given the ease of spoofing sender addresses, and its propensity for use
> in anonymous spamming and trolling (thanks python-list-owner for
> staying on top of that!), I propose to disconnect comp.lang.python from
> the python-list mailing list. Both would then operate independently.
>

As someone who exclusively follows the mailing list, I selfishly want
to support this, as it would notably improve the signal-to-noise
ratio. But I'm aware that there are a number of good people who
currently use the newsgroup, and those people would then be abandoned
in the cess-pool.

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

Proposal: Disconnect comp.lang.python from python-list

[Paul Bryan]

Given the ease of spoofing sender addresses, and its propensity for use
in anonymous spamming and trolling (thanks python-list-owner for
staying on top of that!), I propose to disconnect comp.lang.python from
the python-list mailing list. Both would then operate independently.

Paul

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

[issue43972] Simple HTTP Request Handler in http.server does not set a content-length and does not close connections on 301s

[Senthil Kumaran]

Senthil Kumaran  added the comment:

I am also hesitant to fix something that is not broken. So, please share the 
broken behavior that could be verified, and this will give us greater 
confidence to commit this patch.

--

___
Python tracker 

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

[issue40137] TODO list when PEP 573 "Module State Access from C Extension Methods" will be implemented

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Victor, thanks for the work to mitigate the costs of _PyType_GetModuleByDef().  
It now has much lower overhead.

--

___
Python tracker 

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

[issue42095] plistlib: Add tests that compare with plutil(1)

[Hasan]

Change by Hasan :


Removed file: https://bugs.python.org/file50018/test_plistlib_plutil.py

___
Python tracker 

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

[issue42095] plistlib: Add tests that compare with plutil(1)

[Hasan]

Change by Hasan :


Added file: https://bugs.python.org/file50020/test_plistlib_plutil.py

___
Python tracker 

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

[issue41491] plistlib can't load macOS BigSur system LaunchAgent

[Hasan]

Change by Hasan :


Removed file: https://bugs.python.org/file50019/test_plistlib_plutil.py

___
Python tracker 

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

[issue41491] plistlib can't load macOS BigSur system LaunchAgent

[Hasan]

Change by Hasan :


Added file: https://bugs.python.org/file50019/test_plistlib_plutil.py

___
Python tracker 

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

[issue42095] plistlib: Add tests that compare with plutil(1)

[Hasan]

Change by Hasan :


Removed file: https://bugs.python.org/file50017/test_plistlib_plutil.py

___
Python tracker 

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

[issue42095] plistlib: Add tests that compare with plutil(1)

[Hasan]

Change by Hasan :


Added file: https://bugs.python.org/file50018/test_plistlib_plutil.py

___
Python tracker 

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

[issue44026] IDLE: print "Did you mean?" for AttributeError and NameError

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This is only backported to 3.10 and not 3.9 because the fix recommendations 
were only added in 3.10.

If the code difference became a problem, this could be backported because the 
roundabout method for name and attribute errors would work in 3.9.

--
stage: patch review -> 

___
Python tracker 

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

[issue43972] Simple HTTP Request Handler in http.server does not set a content-length and does not close connections on 301s

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Hi Stephen, 

With the example, I couldn't reproduce the problem with curl 7.65.3

That said, I do recognize that this change is a positive improvement, but I 
cannot see this a bug-fix (and for client misbehavior, which I couldn't verify).

To take a call, I think, this change could go into `main` branch as an 
"improvement" change than a bug-fix. 

Note: the existing behavior is 10+ year old and don't want to introduce changes 
if it is not a bug.


Thanks

--
versions: +Python 3.11 -Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue17681] Work with an extra field of gzip and zip files

[Benjamin Sergeant]

Benjamin Sergeant  added the comment:

type Header struct {
Comment string// comment
Extra   []byte// "extra data"
ModTime time.Time // modification time
Namestring// file name
OS  byte  // operating system type
}

This is what the header/extra things look like for reference.

--

___
Python tracker 

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

[issue17681] Work with an extra field of gzip and zip files

[Benjamin Sergeant]

Benjamin Sergeant  added the comment:

There is a comment field too which would be nice to support.

The Go gzip module has a Header class that describe all the metadata. I see in 
3.8 mtime was made configurable, so hopefully we can add comment and extra.

https://golang.org/pkg/compress/gzip/#Header

For our purpose we'd like to put arbitrary stuff in a gzip file but it is 
complicated to do so, I might use the patch here and apply to the python gzip 
module, but that feels a bit  hackish.

--
nosy: +Benjamin.Sergeant

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset 60ba0b68470a584103e28958d91e93a6db37ec92 by Miss Islington (bot) 
in branch '3.10':
bpo-44022: Fix http client infinite line reading (DoS) after a HTTP 100 
Continue (GH-25916) (GH-25931)
https://github.com/python/cpython/commit/60ba0b68470a584103e28958d91e93a6db37ec92


--

___
Python tracker 

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

[issue42095] plistlib: Add tests that compare with plutil(1)

[Hasan]

Change by Hasan :


Added file: https://bugs.python.org/file50017/test_plistlib_plutil.py

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[miss-islington]

miss-islington  added the comment:


New changeset ea9327036680acc92d9f89eaf6f6a54d2f8d78d9 by Miss Islington (bot) 
in branch '3.9':
bpo-44022: Fix http client infinite line reading (DoS) after a HTTP 100 
Continue (GH-25916)
https://github.com/python/cpython/commit/ea9327036680acc92d9f89eaf6f6a54d2f8d78d9


--

___
Python tracker 

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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Senthil Kumaran]

Senthil Kumaran  added the comment:


New changeset 24f1d1a8a2c4aa58a606b4b6d5fa4305a3b91705 by Miss Islington (bot) 
in branch '3.10':
bpo-43882 Remove the newline, and tab early. From query and fragments. 
(GH-25936)
https://github.com/python/cpython/commit/24f1d1a8a2c4aa58a606b4b6d5fa4305a3b91705


--

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Thanks guangli dong (leveryd)!

This is in and the 3.10-3.6 PRs should automerge (thru 3.9) after the CI runs, 
or be merged by the release managers (3.6-3.8).

--
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

___
Python tracker 

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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[miss-islington]

Change by miss-islington :


--
pull_requests: +24603
pull_request: https://github.com/python/cpython/pull/25936

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[miss-islington]

Change by miss-islington :


--
pull_requests: +24601
pull_request: https://github.com/python/cpython/pull/25934

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[miss-islington]

Change by miss-islington :


--
pull_requests: +24600
pull_request: https://github.com/python/cpython/pull/25933

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[miss-islington]

Change by miss-islington :


--
pull_requests: +24602
pull_request: https://github.com/python/cpython/pull/25935

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[miss-islington]

Change by miss-islington :


--
pull_requests: +24599
pull_request: https://github.com/python/cpython/pull/25932

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

Re: Unsubscribe/can't login

[Greg Ewing]

On 6/05/21 12:58 am, Peter Otten wrote:

Does that happen with all my messages?


I've seen two pairs of duplicate messages from you in this
thread so far, with the same content but slightly different
line wrapping. Looks like a gateway somewhere isn't recognising
them as the same message.

Reading comp.lang.python with Thunderbird.

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

[issue36515] unaligned memory access in the _sha3 extension

[miss-islington]

miss-islington  added the comment:


New changeset 3b2a45ff95a68acc8276b37678c98740a232f6d4 by Miss Islington (bot) 
in branch '3.10':
bpo-36515: Disable unaligned memory access in _sha3 on ARM (GH-25927)
https://github.com/python/cpython/commit/3b2a45ff95a68acc8276b37678c98740a232f6d4


--

___
Python tracker 

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

[issue44046] When writing to the Registry using winreg, it currently allows you to write ONLY to HKEY_CURRENT_USERS.

[William Pickard]

William Pickard  added the comment:

Do you mind ticking the box, "Run as Administrator" in the Compatibility tab 
for python.exe and try winreg again?

--
nosy: +WildCard65

___
Python tracker 

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

[issue44051] Virtualalloc wrong return type

[Eryk Sun]

Eryk Sun  added the comment:

> ctypes.windll.kernel32.VirtuAlloc function return by default 
> a ctypes.c_long

In Windows, ctypes.c_int is an alias for ctypes.c_long, which is a signed 
32-bit integer. This is the default conversion type for the integer parameters 
of an FFI (foreign function interface) call, as well as the result. It's up to 
the author of a library wrapper to define the correct function prototypes, 
pointer types, and aggregate struct/union types. Some common Windows types are 
defined/aliased in the ctypes.wintypes module, but none of the API is 
prototyped.

> ctypes.windll.kernel32.VirtuAlloc

I suggest avoiding the global ctypes.windll loader. IMO, it's not a great idea 
to use a global library loader since it caches WinDLL instances, which cache 
function pointer instances. This make it possible for unrelated projects to 
interfere with each other and the main script by defining incompatible function 
prototypes -- particularly for common Windows API functions. It also doesn't 
allow passing use_last_error=True to enable the safe capturing of the thread's 
last error value as ctypes.get_last_error().

I recommend creating individual CDLL / WinDLL instances. For example:

import ctypes

kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

kernel32.VirtualAlloc.restype = ctypes.c_void_p
kernel32.VirtualAlloc.argtypes = (
ctypes.c_void_p, # lpAddress
ctypes.c_size_t, # dwSize
ctypes.c_ulong,  # flAllocationType
ctypes.c_ulong)  # flProtect

If the call fails, you can raise an OSError as follows:

base_addr = kernel32.VirtualAlloc(None, size, alloc_type, protect)
if base_addr is None:
raise ctypes.WinError(ctypes.get_last_error())

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

___
Python tracker 

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

[issue36515] unaligned memory access in the _sha3 extension

[miss-islington]

Change by miss-islington :


--
pull_requests: +24597
pull_request: https://github.com/python/cpython/pull/25930

___
Python tracker 

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

[issue43976] Allow Python distributors to add custom site install schemes

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Steve: I think the point of discussing whether "pip install" can
be used to manage system wide packages is moot. It's been like that
for ages, not only for pip, but also for the distutils setup.py install
process and the old Makefile.pre.in approach before that. People
have their reasons, it's what you'd expect to work as a Unix sysadmin
and won't go away anytime soon :-)

So back to the original point...

Filipe: Could you please explain why patching sysconfig.py is not a
long term solution ?

This doesn't involve any changes on the CPython side, is as flexible
as you can get (you can also patch functions defined in sysconfig.py
to do the necessary magic, not only provide a static dict),
doesn't create overhead for Python's startup, works with all the
different command line options for limiting sys.path additions and
avoids security issues with the Python import logic.

It's already clear that sysconfig.py will be the new golden source
for installation related APIs and schemes (perhaps this could be
made even clearer in the docs), so 3rd party packages will adapt
to this once 3.10 is out.

--

___
Python tracker 

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

[issue44030] Markup with_traceback code example

[Miguel Brito]

Miguel Brito  added the comment:

If we make it a code snippet it works. Just adding a `::` after the paragraph.

Here's a print on Firefox locally: https://imgur.com/a/g2vsqf2

I created a PR for that if you think it's a good solution, feel free to merge :)

--

___
Python tracker 

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

[issue44030] Markup with_traceback code example

[Miguel Brito]

Change by Miguel Brito :


--
keywords: +patch
nosy: +miguendes
nosy_count: 2.0 -> 3.0
pull_requests: +24596
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25929

___
Python tracker 

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

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

[Mateusz Loskot]

Change by Mateusz Loskot :


--
nosy: +mloskot

___
Python tracker 

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

[issue36515] unaligned memory access in the _sha3 extension

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue44051] Virtualalloc wrong return type

[Steve Dower]

Steve Dower  added the comment:

The return type of a ctypes function is set by whoever is accessing it. If that 
is you, then you should do:

ctypes.windll.kernel32.VirtualAlloc.restype = ctypes.c_void_p

If it's not you, can you point out which code is getting this wrong? ctypes 
defaults to 32-bit int by default because that's what C does, and it has no 
knowledge of the function you're calling to do anything different.

--

___
Python tracker 

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

[issue43976] Allow Python distributors to add custom site install schemes

[Steve Dower]

Steve Dower  added the comment:

>> The best option for restricting the import while still having it be a Python
>> import is to find the file (if it's present in the expected location under
>> sys.whatever), and then use importlib to import it:
>> https://docs.python.org/3/library/importlib.html#importing-a-source-file-directly
>
> Right, though that requires also a new import, importlib, which may not be
> optimal. Considering that this module is meant to be private and basically all
> other private importable parts of Python suffer from the same issue, I am
> finding it hard to justify. If there's enough consensus that this approach 
> would
> be better, I am more than happy to change the implementation.

Another alternative would be to convert sysconfig into a directory and make the 
vendor patch a submodule. That's _very slightly_ more impactful for the 
unpatched case, but only really for scenarios where people are trying to do 
things they shouldn't. Or we can include the file in all distros and import it 
earlier (before taking environment variables, etc. into account).

In my opinion, the security implications alone suggest we shouldn't be 
importing this by name without knowing where it is coming from.

>> I'd rather not have a new option here, I would much prefer "-S" in this
>> context to mean "run Python with only core libraries" and "-s" to mean "run
>> Python with only core and distro libraries" (and neither to mean "run Python
>> with core, distro and user libraries").
>
> I don't think having an option to start Python with only the vendor modules
> would be *necessary*, though it would certainly be helpful. Among other 
> things,
> it would be super helpful to be able to tell users to run Python with the -D
> (made up) option to isolate issues with the vendor modules and the user Python
> environment.

But the user can already exclude their user-installed packages with -s, right? 
It's the site-installed packages that would require -S, but that also excludes 
vendor modules.

Why do we encourage users to install site-wide packages using pip? Why is it 
such an important scenario for a distro-provided Python to be able to modify 
its global install using non-distro-provided tools and non-distro-provided 
packages? What's wrong with saying "install for --user", or else "apt install 
some-different-python-bundle" first and use that?

(To be clear, I'm framing these as confrontational questions to help my 
understanding. I'm totally willing to accept an answer of "just because", 
provided whoever is giving that answer actually "owns" dealing with the 
fallout.)

--

___
Python tracker 

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

[issue44046] When writing to the Registry using winreg, it currently allows you to write ONLY to HKEY_CURRENT_USERS.

[Paul]

Paul  added the comment:

*** Again, I am using a LOCAL ADMINISTRATIVE account. ***

"Actually behind the scenes, winreg uses win32api which doesn't allow setting 
HKEY_LOCAL_MACHINE keys for unprivileged users. Running the application in 
admin mode may work because at that point your application  getting admin 
privileges but it also may not work because winreg module may not gain admin 
privileges even though your application does."

That is not correct.  What special permissions do I need to leverage winreg to 
write to HKEY_LOCAL_MACHINE that a normal local administrator does not have?  
By default, any user that has adequate permissions to write / modify directly 
to their HKCU hive, can also do so in HKEY_LOCAL_MACHINE.  The only isolated 
exceptions are where there are specialized keys in which custom permissions 
were modified outside the default inherited permissions.  To be clear, there is 
no "admin mode", but I think what you mean is being logged in either with local 
Administrator account, or logged in with an account that has local 
Administrator permissions.  (You can either be logged in as Administrator, or 
have an account that has local admin privileges, both of which I am doing when 
I am executing winreg methods that fail with permission errors.)

"When you run regedit you get an admin pop up, right? Like that also run python 
in admin mode."

No, there is no pop up.  The reason there is no pop up is because as explained 
previously, my account has local administrative permissions, and secondly, I 
have UAC turned off.  I can freely make changes directly to the Registry in any 
hive, including HKEY_LOCAL_MACHINE.  This is NOT a permissions issue in the 
Registry and / or with the user account I am using.  If there is a permission 
issue do to a lack of proper winreg security flag, then that is different, and 
I need to understand which winreg security flag(s) I SHOULD be using so I can 
correct it.   You don't want popups, especially for processes you want to run 
automatically and unattended, right?  If there was a pop up during an attempted 
change to the Registry, then any methods used would otherwise not have a chance 
to execute correctly, and any application doing this would obviously break.

"I've never used C# but as far as I know it doesn't use win32api while Python 
does. C# is specifically designed to work with these while C is not therefore 
it uses win32api. Python uses the C interface of win32api."

Actually, C++ and C# uses Win32 API through .NET framework, while also allows 
even more intimate and direct connection to Win32 (both in managed and 
unmanaged interfaces).  Obviously, due to the differences of outcomes, while 
the interfaces winreg is using to access the Registry are similar, apparently 
they are quite different, as I can run equivalent Registry functions in C# with 
C++ Win32 API, and it runs just fine.  Again, no permission issues at all.

"Please provide an example that does not involve setting of values (I actually 
don't want to mess with my registry). If this is occurring while setting of 
values then I am on right track. If it's not then this requires quite a 
investigation and debugging. "

No, you are not on track yet.  How can you test a defect in winreg of writing 
to HKEY_LOCAL_MACHINE without actually trying to write to it?  You can't, and 
you are not even investigating it yet.  

If you are not going to leverage the examples provided, then how are you going 
to learn about this winreg defect? If you don't like the Registry values in the 
examples, then simply change them to something you are more comfortable with 
that is equally as innocuous as my examples, as long as you use HKCU on one, 
and run the exact same one pointed to HKLM, so that you can very quickly and 
easily see for yourself, and reproduce this defect.  If your account 
permissions are set up correctly and mine are not, then BOTH examples I gave 
you should execute and write Registry settings to both HKCU and HKLM, without 
any errors.

After running into this issue and reviewing documentation all over again, I 
also see a pattern that every example out there only uses HKCU hive, while 
there are zero working examples that demonstrate writing to the Registry in the 
HKEY_LOCAL_MACHINE. This no longer appears to be just a coincidence, but 
instead a limitation.  While HKCU is quite common for user-specific Registry 
settings, HKLM is very heavily used for nearly everything that is not 
user-specific settings.  For winreg not being able to write to HKLM hive 
successfully, regardless if the user is a local admin and has inherited admin 
privileges to HKLM even by default, then this is a major bug and a huge 
limitation to winreg that someone should investigate and implement a solution.  
  

Also, if you are not going to run the examples I provided (even with your own 
Registry values you are comfortable with), then provide ONE working example of 
writing to Registry with 

Re: [OT] Annoying message duplication, was Re: Unsubscribe/can't login

[Peter Otten]

On 05/05/2021 20:08, Jan van den Broek wrote:

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

On 05/05/2021 16:10, Ethan Furman wrote:


I see your messages twice (occasionally with other posters as well).?? I
have no idea how to fix it.?? :(


OK, I'll try another option from Thunderbird's context menu: Followup to
Newsgroup.

Does that appear once or twice?


Here, once.


OK, thanks Jan for bringing this up. From now on I'll try to use the 
"followup" option consistently.


All, if you see duplicate posts more than once in a while you may inform 
me -- private mail is probably preferred by those who don't ;).



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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Mike: There may be multiple ways to read that WHATWG recommendation?  The 
linked to section is about implementing a state machine for parsing a URL into 
parts safely.  But that may not imply that anything that passed through that 
state machine should be considered "valid".  Just that this spec is able to 
make some sense out of otherwise messy data.  Network adage: Be lenient in what 
you accept.  I doubt anyone would want something producing URLs for consumption 
by something else to allow these in their output.

I have yet to read the _entire_ WHATWG spec from head to toe to try and better 
understand the context they had in mind.

I agree that it is unfortunate that the original URL may have these issues and 
go on to be (re)used in another context where it passes to something that might 
not treat it in the same manner.  That's in some sense a flaw in our API design 
that we allow string based URLs to be used in APIs rather than require them to 
have gone through a parsing sanitization step into a instance of a URL object 
(for example). API design like that is clearly out of scope for this issue. :)

Regardless my gut feeling is that we continue with the existing fix that remove 
the characters as we've already started releasing.  If we need to change our 
mind on how we've done that, so be it, we can, that'll show up in later patches.

--

___
Python tracker 

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

[issue44046] When writing to the Registry using winreg, it currently allows you to write ONLY to HKEY_CURRENT_USERS.

[Eryk Sun]

Eryk Sun  added the comment:

> There is no reason why a user should be able to write to 
> HKCU but not HKLM.  

Modifying system keys is limited to SYSTEM, administrators, and various 
privileged accounts and services such as TrustedInstaller. Standard users are 
not allowed to modify system keys.

> User is a local admin on the machine, and UAC is disabled as well. 

Please show the output from running the following:

import subprocess
import winreg

print(subprocess.check_output('whoami.exe /groups /fo list', text=True))

hkey = winreg.HKEY_LOCAL_MACHINE
winreg.OpenKey(hkey, 'SOFTWARE', 0, winreg.KEY_ALL_ACCESS)

If it shows that the administrators group is enabled but full access is still 
denied to the system "SOFTWARE" hive, then something peculiar is happening here 
that warrants further inspection.

---

Background

The base object type that implements the registry is the Key type. A key object 
can contain other keys and values, or a symbolic link to another key. A key can 
also be mounted by a hive, which is a tree of keys that's persisted in a file.

The root key is named "\REGISTRY". The system mounts user profile hives (i.e. 
"\NTUSER.DAT") on subkeys of "\REGISTRY\USER" and system hives on 
subkeys of "\REGISTRY\MACHINE". Each loaded user profile hive is mounted on a 
subkey that's named for the user's SID string -- e.g. 
"\REGISTRY\USER\S-1-5-21--", except the default user 
profile hive is mounted as "\REGISTRY\USER\.DEFAULT". The mounted system hives 
include BCD (boot configuration database), SYSTEM, SOFTWARE, SECURITY, 
and SAM. The system hives, with the exception of the BCD hive, are found on 
disk in the directory "%SystemRoot%\System32\config". 

The "\REGISTRY\USER" and "\REGISTRY\MACHINE" keys are made available via the 
predefined handles HKEY_USERS and HKEY_LOCAL_MACHINE. These predefined handles 
can also reference the "USER" and "MACHINE" keys on a remote system via 
winreg.ConnectRegistry(). In the local case, the API maps the predefined handle 
to an actual handle that it opens via NtOpenKeyEx(). In the remote case, the 
predefined handle is mapped to an RPC (remote procedure call) handle that 
proxies a handle on the remote system.

HKEY_CURRENT_USER is a predefined handle for the user profile key of the 
current user. It exists for convenience. Otherwise a program would have to get 
the name of the subkey to use by getting the current user's SID as a string.

The predefined handles that are documented to work with ConnectRegistry() are 
HKEY_USERS, HKEY_LOCAL_MACHINE, and HKEY_PERFORMANCE_DATA (a virtual key that 
the API implements) [1]. ConnectRegistry() is not documented to support 
HKEY_CURRENT_USER. For a remote system, it opens the default profile. This is 
undefined behavior for an unsupported parameter. It happens to work in the 
local case when computer_name is None.

A key object is secured by a security descriptor that grants or denies specific 
users and groups various standard rights and specific key rights. winreg 
provides the API constants for specific key rights, as well as constants with 
mapped rights for generic access, including KEY_READ, KEY_WRITE, KEY_EXECUTE, 
and KEY_ALL_ACCESS. These are defined as follows:

STANDARD_RIGHTS_REQUIRED:
WRITE_OWNER
WRITE_DAC
READ_CONTROL
DELETE

KEY_READ / KEY_EXECUTE:
KEY_QUERY_VALUE
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
READ_CONTROL

KEY_WRITE:
KEY_SET_VALUE
KEY_CREATE_SUB_KEY
READ_CONTROL

KEY_ALL_ACCESS:
KEY_READ
KEY_WRITE
KEY_CREATE_LINK
STANDARD_RIGHTS_REQUIRED

>From the command line, you can use Sysinternals "accesschk.exe" to check the 
>access that a key grants to a particular user or group, such as the "Users" 
>group. For example:

C:\>accesschk -nobanner -kdv Users "HKLM\SOFTWARE\Microsoft\Windows 
NT\CurrentVersion\Winlogon"
R  HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
KEY_QUERY_VALUE
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
READ_CONTROL

Standard users are only granted read access to the "Winlogon" key. Full access 
is granted to administrators, SYSTEM, and the TrustedInstaller service. 

By default, if UAC is enabled, an administrator uses a non-elevated logon that 
has the administrators group disabled for everything except denying access to 
objects. Spawning a process with "run as administrator" uses an elevated logon 
that enables the administrators group for granting access to secured objects.

---

[1] 
https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regconnectregistryw

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[Gregory P. Smith]

Gregory P. Smith  added the comment:

The bug: Our http client can get stuck infinitely reading len(line) < 64k lines 
after receiving a '100 Continue' http response.  So yes, this could lead to our 
client being a bandwidth sink for anyone in control of a server.

Clear issue: That's a denial of network bandwidth and the denial of service in 
terms of CPU needed to process read and skip such lines.  The infinite lines 
are size bounded and are not buffered so there is no memory based DoS.

Maybe issue: If a the underlying socket has a timeout set on it, it can be used 
to prevent the timeout from triggering by sending a line more often than the 
timeout.  this is a denial of service by making a http client connection that 
an author may have assumed would timeout based on their 
socket.setdefaulttimeout() settings hang forever.

I expect there are plenty of other ways to accomplish the latter in our http 
client code though.  Ex: A regular response with a huge content length where 
one byte is transmitted occasionally could also effectively accomplish that.  
The stdlib http stack doesn't have its own overall http transaction timeout as 
a feature.

--

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[Gregory P. Smith]

Change by Gregory P. Smith :


--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
title: "urllib" will result to deny of service -> urllib http client possible 
infinite loop on a 100 Continue response
versions: +Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

[issue40617] sqlite3: expose sqlite3_create_window_function

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add create_window_function() to sqlite3.Connection

___
Python tracker 

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

[issue37903] IDLE Shell sidebar.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

As described above in msg392163, the other fix is to put the prompt on a line 
by itself.  I hoped to get a switch between fixes into b1 but ran out of time 
and energy.  I intend to have in in the next, along with other improvements.

--

___
Python tracker 

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

[issue44050] Exceptions in a subinterpreter are changed by another subinterpreter

[Gregory P. Smith]

Change by Gregory P. Smith :


--
assignee:  -> eric.snow
nosy: +eric.snow

___
Python tracker 

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

[issue44043] 3.10 b1 armhf Bus Error in hashlib test: test_gil

[Gregory P. Smith]

Change by Gregory P. Smith :


--
dependencies: +unaligned memory access in the _sha3 extension

___
Python tracker 

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

[issue36515] unaligned memory access in the _sha3 extension

[Gregory P. Smith]

Change by Gregory P. Smith :


--
pull_requests: +24594
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25927

___
Python tracker 

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

Re: Transistion from module to package and __init__.py

[Dieter Maurer]

Chris Nyland wrote at 2021-5-4 22:20 -0400:
> ...
>So for a while now I have taken to converting
>my module, in this example database.py, to the __init__.py of the package.
>I remember reading years back that having code in the __init__.py was bad
>practice but I can't remember reading for any specific reason.

If your package is not a so called "namespace package"
(this is a package components of which are stored in different places
and can be installed independent from one another), then
I see no reason not to put code into `__init__.py`.

When I transform a module into a package, I start by using the former
module as the new package's `__init__.py`. Later refactoring steps may
move things out into separate modules/subpackages.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue44046] When writing to the Registry using winreg, it currently allows you to write ONLY to HKEY_CURRENT_USERS.

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

> I can also add, modify, and delete Registry entries in HKLM (or any other 
> hive) by hand with no problem, so it is definitely not a permissions issue.

When you run regedit you get an admin pop up, right? Like that also run python 
in admin mode.

> I can also write, update, modify, etc. anything in HKLM using C# just fine, 
> but NOT with winreg in Python.  

I've never used C# but as far as I know it doesn't use win32api while Python 
does. C# is specifically designed to work with these while C is not therefore 
it uses win32api. Python uses the C interface of win32api. 

> Keep in mind that the exact same Registry write methods work as long as you 
> are pointed to HKCU hive. However, if you point to HKLM and do not change 
> anything else, winreg will throw a permissions error every time, no matter 
> what combination of permission flags you specify.
> You will be able to reproduce and see the problem if you try the two examples 
> I provided.  Have you tried the two code snippets I provided yet?  Please do 
> so, and confirm the outcome so that you are on the same page.

Please provide an example that does not involve setting of values (I actually 
don't want to mess with my registry). If this is occurring while setting of 
values then I am on right track. If it's not then this requires quite a 
investigation and debugging. 


Lastly a WinError always means Access Denied. AFAICT this is a permission 
problem.

--

___
Python tracker 

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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Mike Lissner]

Mike Lissner  added the comment:

> I'd wonder how to pass through valid exceptions without urlparse raising 
> something.

Oops, meant to say "valid URLs", not valid exceptions, sorry.

--

___
Python tracker 

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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Mike Lissner]

Mike Lissner  added the comment:

> Instead of the patches as you see them, we could've raised an exception.

In my mind the definition of a valid URL is what browsers recognize. They're 
moving towards the WHATWG definition, and so too must we. 

If we make python raise an exception when a URL has a newline in the scheme 
(e..g: "htt\np"), we'd be raising exceptions for *valid* URLs as browsers 
define them. That doesn't seem right at all to me. I'd be frustrated to have to 
catch such an exception, and I'd wonder how to pass through valid exceptions 
without urlparse raising something.


> Making the output 'sanitized' means that invalid input is converted into 
> valid output.  This goes against the principle of least surprise.

Well, not quite, right? The URLs this fixes *are* valid according to browsers. 
Browsers say these tabs and newlines are OK. 



I agree though that there's an issue with the approach of stripping input in a 
way that affects output. That doesn't seem right. 

I think the solution I'd favor (and I imagine what's coming in 43883) is to do 
this properly so that newlines are preserved in the output, but so that the 
scheme is also placed properly in the scheme attribute. 

So instead of this (from the initial report):

> In [9]: from urllib.parse import urlsplit
> In [10]: urlsplit("java\nscript:alert('bad')")
> Out[10]: SplitResult(scheme='', netloc='', path="java\nscript:alert('bad')", 
> query='', fragment='')

We get something like this:

> In [10]: urlsplit("java\nscript:alert('bad')")
> Out[10]: SplitResult(scheme='java\nscript', netloc='', path="alert('bad')", 
> query='', fragment='')

In other words, keep the funky characters and parse properly.

--

___
Python tracker 

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

[issue36515] unaligned memory access in the _sha3 extension

[Gregory P. Smith]

Gregory P. Smith  added the comment:

that patch looks fine, i'll turn it into a PR.

--
assignee: christian.heimes -> gregory.p.smith
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

[issue36515] unaligned memory access in the _sha3 extension

[Gregory P. Smith]

Change by Gregory P. Smith :


--
assignee:  -> christian.heimes
versions: +Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

Re: neoPython : Fastest Python Implementation: Coming Soon

[Ian Clark]

I wish you best of luck, on top of everything else it looks like the
neopython namespace has already been eaten up by some crypto project

On Wed, May 5, 2021 at 11:18 AM Benjamin Schollnick <
bscholln...@schollnick.net> wrote:

> > Why? The currently extant Python implementations contribute to climate
> change as they are so inefficient;
>
> That same argument can be made for every triple-AAA video game, game
> console, etc.
>
> Python is more efficient for some problem sets, and Python is less
> efficient for other problem sets.
>
> Please feel free to come out with NeoPython.  When you are done, and it is
> backward compatible with existing Python code, I’ll be happy to benchmark
> it against Native python.  But don’t blame Python for global climate
> change.  There are plenty of bigger “causations” to Global climate change,
> then a freakin’ computer programming language.
>
> - Benjamin
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: neoPython : Fastest Python Implementation: Coming Soon

[Benjamin Schollnick]

> Why? The currently extant Python implementations contribute to climate change 
> as they are so inefficient; 

That same argument can be made for every triple-AAA video game, game console, 
etc.

Python is more efficient for some problem sets, and Python is less efficient 
for other problem sets.

Please feel free to come out with NeoPython.  When you are done, and it is 
backward compatible with existing Python code, I’ll be happy to benchmark it 
against Native python.  But don’t blame Python for global climate change.  
There are plenty of bigger “causations” to Global climate change, then a 
freakin’ computer programming language.

- Benjamin


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

[issue43795] Implement PEP 652 -- Maintaining the Stable ABI

[miss-islington]

miss-islington  added the comment:


New changeset 8f3ef457ad286e73f272dadec8b98d2ea3a6ec72 by Miss Islington (bot) 
in branch '3.10':
bpo-43795: Mark PyCodec_Unregister as a function, not data, in stable ABI 
(GH-25920)
https://github.com/python/cpython/commit/8f3ef457ad286e73f272dadec8b98d2ea3a6ec72


--

___
Python tracker 

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

Re: [OT] Annoying message duplication, was Re: Unsubscribe/can't login

[Jan van den Broek]

On 2021-05-05, Peter Otten <__pete...@web.de> wrote:
> On 05/05/2021 16:10, Ethan Furman wrote:
>
>> I see your messages twice (occasionally with other posters as well).?? I 
>> have no idea how to fix it.?? :(
>
> OK, I'll try another option from Thunderbird's context menu: Followup to 
> Newsgroup.
>
> Does that appear once or twice?

Here, once.

-- 
Jan v/d Broek
balgl...@dds.nl
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Thanks Florian!  Indeed, I'm glad you have tests for this.  (I expect anyone 
writing their own validation code will have such tests)

Making urlsplit raise an exception where it never has before has other 
consequences:

In CPython's own test suite test_urllib fails as many of its tests for 
validation that these characters are either ignored or cause a specific 
http.client.InvalidURL error on urlopen() start failing.  I draw no conclusions 
from that other than we'd need to rework some of those tests.  It just reflects 
the state of our test suite and even inconsistent behavior between excluding 
the characters or erroring within the http.client code on them based on past 
CVEs.

Regardless, if people would people prefer to see urlsplit `raise 
SomeExistingException(f'Invalid characters in URL or scheme. url={url!r} 
scheme={scheme!r}')` in 3.9.6 and the security patch releases for other 3.x 
versions, evidence that it wouldn't cause alternate problems would be helpful.

I've kicked off tests at work on our huge codebase with both variants as a 
datapoint to see if that is informative or not.

If we went the exception route: SomeExistingException might make sense as 
`http.client.InvalidURL`, but that'd be a circular dependency (no big deal) and 
heavyweight import for urllib.parse to have.  `urllib.error.URLError` could 
also make sense, but that's an OSError descendant and identifies itself as a 
urlopen error which would be surprising.  `ValueError` is a reasonable 
fallback.  But using that guarantees someone will wonder why it isn't one of 
the other two...  As this is a bugfix, defining a new exception isn't an option.

We as a community currently lack a way for security patches to CPython to be 
tested against a broad swath of projects in advance of them appearing in a 
release.  Once upon a time there were release candidates for patches releases 
that could serve this purpose...

--

___
Python tracker 

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

[issue37903] IDLE Shell sidebar.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Is it possible to add a Settings option under the General tab to switch between 
the sidebar mode and traditional mode?

--

___
Python tracker 

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

Re: [OT] Annoying message duplication, was Re: Unsubscribe/can't login

[Jan van den Broek]

On 2021-05-05, Jim Byrnes  wrote:
> On 5/5/21 9:39 AM, Peter Otten wrote:
>> On 05/05/2021 16:10, Ethan Furman wrote:
>> 
>>> I see your messages twice (occasionally with other posters as well).  
>>> I have no idea how to fix it.?? :(
>> 
>> OK, I'll try another option from Thunderbird's context menu: Followup to 
>> Newsgroup.
>> 
>> Does that appear once or twice?
>> 
>> In theory it should go to the newsgroup only which would mirror it to 
>> the list.
>> 
>
> FWIW, none of the messages in this this thread are dupes for me and I 
> can't remember the last time I saw a dupe from you.

Are you reading this via the mailinglist or Usenet?
-- 
Jan v/d Broek
balgl...@dds.nl
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35753] Importing call from unittest.mock directly causes ValueError

[Łukasz Langa]

Łukasz Langa  added the comment:

Fixed in 3.10 and 3.11, thanks Albert for your patch.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.11 -Python 3.7

___
Python tracker 

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

Re: Transistion from module to package and __init__.py

[Ethan Furman]

On 5/4/21 7:20 PM, Chris Nyland wrote:

> Here is
> where I my primary design question comes in. As organized now as described
> to import and use the package I need
>
> from database import database
>
> or I have to put in the init file
>
> from database import *
>
> Either of these still leaves a database.database namespace laying about and
> to me it just seems untidy. So for a while now I have taken to converting
> my module, in this example database.py, to the __init__.py of the package.

> So I was hoping to get
> feed back from a wider audience about if there are any issues with this
> type of design that I just haven't encounter yet or find out what other
> people do with this same problem.

This is the same method I use, and it works fine for smaller packages.  I do have one package, dbf, that I am in the 
process of converting to multiple files simply because there is so much (10k lines for me, YMMV).


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

[issue35753] Importing call from unittest.mock directly causes ValueError

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 10d6f6bfd749c0e7da51a96f53ca326c336f7a00 by Miss Islington (bot) 
in branch '3.10':
bpo-35753: Fix crash in doctest with unwrap-able functions (GH-22981) (#25926)
https://github.com/python/cpython/commit/10d6f6bfd749c0e7da51a96f53ca326c336f7a00


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue41282] Deprecate and remove distutils

[Filipe Laíns]

Filipe Laíns  added the comment:

That always depends on the way distros patch Python, though all the major 
distros I know will add their schemes to sysconfig, which works what that 
approach. But yeah, that is what you probably want to be doing :)

--

___
Python tracker 

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

[issue35753] Importing call from unittest.mock directly causes ValueError

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue43795] Implement PEP 652 -- Maintaining the Stable ABI

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +24592
pull_request: https://github.com/python/cpython/pull/25925

___
Python tracker 

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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[miss-islington]

Change by miss-islington :


--
pull_requests: +24590
pull_request: https://github.com/python/cpython/pull/25923

___
Python tracker 

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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[miss-islington]

Change by miss-islington :


--
pull_requests: +24591
pull_request: https://github.com/python/cpython/pull/25924

___
Python tracker 

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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 515a7bc4e13645d0945b46a8e1d9102b918cd407 by Miss Islington (bot) 
in branch '3.8':
[3.8] bpo-43882 - urllib.parse should sanitize urls containing ASCII newline 
and tabs. (GH-25595) (#25726)
https://github.com/python/cpython/commit/515a7bc4e13645d0945b46a8e1d9102b918cd407


--

___
Python tracker 

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

[issue44046] When writing to the Registry using winreg, it currently allows you to write ONLY to HKEY_CURRENT_USERS.

[Paul]

Paul  added the comment:

Clarification:
User is a local admin on the machine, and UAC is disabled as well.  I can also 
add, modify, and delete Registry entries in HKLM (or any other hive) by hand 
with no problem, so it is definitely not a permissions issue.  I can also 
write, update, modify, etc. anything in HKLM using C# just fine, but NOT with 
winreg in Python.  

Note:  Keep in mind that the exact same Registry write methods work as long as 
you are pointed to HKCU hive. However, if you point to HKLM and do not change 
anything else, winreg will throw a permissions error every time, no matter what 
combination of permission flags you specify.  There is no reason why a user 
should be able to write to HKCU but not HKLM.  Try it and you will experience 
the same.  This is clearly a major bug and should be fixed.  It severely limits 
developers from writing to other Registry hives.  While HKCU is quite common to 
use, HKLM is the most common that developers use, especially when you don't 
want specific Registry keys to be accessible only to a specific user.

You will be able to reproduce and see the problem if you try the two examples I 
provided.  Have you tried the two code snippets I provided yet?  Please do so, 
and confirm the outcome so that you are on the same page.

--

___
Python tracker 

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

Re: neoPython : Fastest Python Implementation: Coming Soon

[Igor Korot]

Hi,

On Wed, May 5, 2021 at 11:47 AM Mr Flibble <
flib...@i42.invalidwibblegrok.co.uk> wrote:

> On 05/05/2021 17:36, Igor Korot wrote:
> > Hi,
> >
> > On Wed, May 5, 2021 at 11:27 AM Mr Flibble <
> > flib...@i42.invalidwibblegrok.co.uk> wrote:
> >
> >> On 05/05/2021 17:02, Chris Angelico wrote:
> >>> On Thu, May 6, 2021 at 2:01 AM Mr Flibble
> >>>  wrote:
> 
>  neoPython : Fastest Python Implementation: Coming Soon
> 
>  Message ends.
> 
>  /Flibble
> 
> >>>
> >>> My breath: not being held.
> >>>
> >>> Message ends.
> >>
> >> Why? The currently extant Python implementations are so inefficient they
> >> contribute to climate change; CPython is particularly egregious. Making
> a
> >> faster
> >> implementation isn't in the least bit a stretch.
> >>
> >> Message ends.
> >>
> >
> > Why do you use {C}Python in the first place if its so inefficient?
> > Why not use C or even Assembly?
> >
> > And "coming soon" - is a little weird.
> > Why not say "coming 10 May 2021 at 23:59:59"?
> >
> > /Message ends.
> >
> > Thank you.
>
> But I don't use Python, I use C++ (probably the best programming language
> in the
> world).
>

Posting in the python community implies that you are using {c}python.
Otherwise you will not be posting here.
And definitely would be waiting until you can show the "best python
implementation ever".

And C++ is also bad - Assembly is so much better and so much more efficient.

/Message ends.

Thank you.


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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Senthil Kumaran]

Change by Senthil Kumaran :


--
pull_requests: +24589
pull_request: https://github.com/python/cpython/pull/25921

___
Python tracker 

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

Re: neoPython : Fastest Python Implementation: Coming Soon

[Mr Flibble]

On 05/05/2021 17:36, Igor Korot wrote:

Hi,

On Wed, May 5, 2021 at 11:27 AM Mr Flibble <
flib...@i42.invalidwibblegrok.co.uk> wrote:


On 05/05/2021 17:02, Chris Angelico wrote:

On Thu, May 6, 2021 at 2:01 AM Mr Flibble
 wrote:


neoPython : Fastest Python Implementation: Coming Soon

Message ends.

/Flibble



My breath: not being held.

Message ends.


Why? The currently extant Python implementations are so inefficient they
contribute to climate change; CPython is particularly egregious. Making a
faster
implementation isn't in the least bit a stretch.

Message ends.



Why do you use {C}Python in the first place if its so inefficient?
Why not use C or even Assembly?

And "coming soon" - is a little weird.
Why not say "coming 10 May 2021 at 23:59:59"?

/Message ends.

Thank you.


But I don't use Python, I use C++ (probably the best programming language in the 
world).


/Flibble

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

Re: neoPython : Fastest Python Implementation: Coming Soon

[Mr Flibble]

On 05/05/2021 17:33, Mark Lawrence wrote:

On Wednesday, May 5, 2021 at 4:57:13 PM UTC+1, Mr Flibble wrote:

neoPython : Fastest Python Implementation: Coming Soon

Message ends.

/Flibble

--


Dedicated to you and all like you https://www.youtube.com/watch?v=X15PsqN0DHc


ORLY? If anyone is thick around here it is the typical Python user such as 
yourself.

/Flibble

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

[issue41282] Deprecate and remove distutils

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș  added the comment:

Alright so to get all the package paths, included distro-managed ones would be 
this right?

for scheme in sysconfig.get_scheme_names():
 for name in ['purelib', 'platlib']:
  sysconfig.get_path(name, scheme)

--

___
Python tracker 

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

Re: neoPython : Fastest Python Implementation: Coming Soon

[Igor Korot]

Hi,

On Wed, May 5, 2021 at 11:27 AM Mr Flibble <
flib...@i42.invalidwibblegrok.co.uk> wrote:

> On 05/05/2021 17:02, Chris Angelico wrote:
> > On Thu, May 6, 2021 at 2:01 AM Mr Flibble
> >  wrote:
> >>
> >> neoPython : Fastest Python Implementation: Coming Soon
> >>
> >> Message ends.
> >>
> >> /Flibble
> >>
> >
> > My breath: not being held.
> >
> > Message ends.
>
> Why? The currently extant Python implementations are so inefficient they
> contribute to climate change; CPython is particularly egregious. Making a
> faster
> implementation isn't in the least bit a stretch.
>
> Message ends.
>

Why do you use {C}Python in the first place if its so inefficient?
Why not use C or even Assembly?

And "coming soon" - is a little weird.
Why not say "coming 10 May 2021 at 23:59:59"?

/Message ends.

Thank you.


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

[issue43976] Allow Python distributors to add custom site install schemes

[Filipe Laíns]

Filipe Laíns  added the comment:

We cannot change how `sudo pip install` fundamentally works because there are 
too many people depending on it, and even if we could, this is not the place :P

I think we went a little off-topic here, so let's get back to the discussion.

> The best option for restricting the import while still having it be a Python 
> import is to find the file (if it's present in the expected location under 
> sys.whatever), and then use importlib to import it: 
> https://docs.python.org/3/library/importlib.html#importing-a-source-file-directly

Right, though that requires also a new import, importlib, which may not be 
optimal. Considering that this module is meant to be private and basically all 
other private importable parts of Python suffer from the same issue, I am 
finding it hard to justify. If there's enough consensus that this approach 
would be better, I am more than happy to change the implementation.

> I'd rather not have a new option here, I would much prefer "-S" in this 
> context to mean "run Python with only core libraries" and "-s" to mean "run 
> Python with only core and distro libraries" (and neither to mean "run Python 
> with core, distro and user libraries").

I don't think having an option to start Python with only the vendor modules 
would be *necessary*, though it would certainly be helpful. Among other things, 
it would be super helpful to be able to tell users to run Python with the -D 
(made up) option to isolate issues with the vendor modules and the user Python 
environment.

> That may be a bigger change, but there's enough angst around this issue that 
> we would be better off getting it right this time, even if it changes things, 
> than continuing to preserve the system that people dislike so much.

This may be completely wrong for other people, but is my understanding. AFAIK 
those these issues come from lack of separation between the distro, system and 
user environments, causing a hell of conflicts and silent module shadowing that 
neither the system package manager or pip can fix. Almost every time I help 
people with Python I have to tell them to use a virtual env, which most people 
aren't expecting, and would likely run into issues had I not suggested it.
Considering that, I think this approach, including the CLI option, would be a 
step forward. How big would that step be, I am not sure, but probably not 
*that* big.

But yeah, this is, of course, my experience, and that can vary for other 
people, so there may be different perspectives here. So I'd very much like to 
hear other people on this.

--

___
Python tracker 

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

[issue41282] Deprecate and remove distutils

[Filipe Laíns]

Filipe Laíns  added the comment:

If you are relying on the value of distutils.sysconfig.get_python_lib() as you 
shown in your system, you probably don't want to. That directory 
(dist-packages) should be for Debian provided packages only, so moving to 
sysconfig.get_path() would be a good thing, as it has the correct value for 
user installed packages on your system.

But anyway, there have been introduced mechanisms that should allow distros to 
deal with these issues. The goal is to make it so that distros can officially 
customize such details and not have to rely on heavy patching.

--

___
Python tracker 

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

[issue43795] Implement PEP 652 -- Maintaining the Stable ABI

[Petr Viktorin]

Change by Petr Viktorin :


--
pull_requests: +24588
pull_request: https://github.com/python/cpython/pull/25920

___
Python tracker 

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

[issue44017] Deprecation warning in tests over no current event loop

[Dong-hee Na]

Change by Dong-hee Na :


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

Re: neoPython : Fastest Python Implementation: Coming Soon

[Mr Flibble]

On 05/05/2021 17:02, Chris Angelico wrote:

On Thu, May 6, 2021 at 2:01 AM Mr Flibble
 wrote:


neoPython : Fastest Python Implementation: Coming Soon

Message ends.

/Flibble



My breath: not being held.

Message ends.


Why? The currently extant Python implementations are so inefficient they 
contribute to climate change; CPython is particularly egregious. Making a faster 
implementation isn't in the least bit a stretch.


Message ends.

/Flibble

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

[issue44017] Deprecation warning in tests over no current event loop

[Dong-hee Na]

Change by Dong-hee Na :


--
keywords: +patch
nosy: +corona10
nosy_count: 5.0 -> 6.0
pull_requests: +24587
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25918

___
Python tracker 

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

Re: neoPython : Fastest Python Implementation: Coming Soon

[Mr Flibble]

On 05/05/2021 17:02, Chris Angelico wrote:

On Thu, May 6, 2021 at 2:01 AM Mr Flibble
 wrote:


neoPython : Fastest Python Implementation: Coming Soon

Message ends.

/Flibble



My breath: not being held.

Message ends.


Why? The currently extant Python implementations contribute to climate change as 
they are so inefficient; CPython is so egregious it is best called a bag of 
shite. Making a faster implementation isn't in the least bit a stretch.


Message ends.

/Flibble

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

[issue41282] Deprecate and remove distutils

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș  added the comment:

That seems fine, tho for some of distros that do lots of python customizations 
(tried the docker ubuntu image for 18.04.3) it get a bit strange:

Python 3.6.9 (default, Jan 26 2021, 15:33:00)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> import distutils.sysconfig
>>> sysconfig.get_path('platlib')
'/usr/lib/python3.6/site-packages'
>>> sysconfig.get_path('purelib')
'/usr/lib/python3.6/site-packages'
>>> distutils.sysconfig.get_python_lib()
'/usr/lib/python3/dist-packages'

--

___
Python tracker 

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

[issue44051] Virtualalloc wrong return type

[baptistecrepin]

New submission from baptistecrepin :

The ctypes.windll.kernel32.VirtuAlloc function return by default a 
ctypes.c_long but on 64bits systems memory addresses can be higher so it should 
be a ctypes.c_uint64 or ctypes.c_void_p.

--

___
Python tracker 

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

[issue44051] Virtualalloc wrong return type

[baptistecrepin]

Change by baptistecrepin :


--
components: Windows
nosy: baptistecrepin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Virtualalloc wrong return type
type: behavior
versions: Python 3.9

___
Python tracker 

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

Re: neoPython : Fastest Python Implementation: Coming Soon

[Chris Angelico]

On Thu, May 6, 2021 at 2:01 AM Mr Flibble
 wrote:
>
> neoPython : Fastest Python Implementation: Coming Soon
>
> Message ends.
>
> /Flibble
>

My breath: not being held.

Message ends.

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

Re: [OT] Annoying message duplication, was Re: Unsubscribe/can't login

[Jim Byrnes]

On 5/5/21 9:39 AM, Peter Otten wrote:

On 05/05/2021 16:10, Ethan Furman wrote:

I see your messages twice (occasionally with other posters as well).  
I have no idea how to fix it.  :(


OK, I'll try another option from Thunderbird's context menu: Followup to 
Newsgroup.


Does that appear once or twice?

In theory it should go to the newsgroup only which would mirror it to 
the list.




FWIW, none of the messages in this this thread are dupes for me and I 
can't remember the last time I saw a dupe from you.


Regards,  Jim

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