[issue46528] Simplify the VM's stack manipulations

2022-01-27 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

IIRC, Carl got a lot of benefit out of reordering the opcodes in the main loop 
to put the most common ones at the top.  I don't know if that is still relevant 
or whether computed gotos, when enabled, change that calculus.

--

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



[issue46528] Simplify the VM's stack manipulations

2022-01-27 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Very interesting.  Do we have any current (or even cutting edge, i.e. 3.11) 
timings for individual instructions?  Or a breakdown of how frequently 
different instructions are invoked?  I remember Carl Shapiro presenting his 
findings here several years ago (I think in the penultimate in-person Language 
Summit).

--

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



[issue46528] Simplify the VM's stack manipulations

2022-01-25 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

What are the (unoptimized) performance implications of replacing one 
instruction with multiple instructions?

--
nosy: +barry

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



[issue46330] Simplify the signature of __exit__

2022-01-11 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue46328] add sys.exception()

2022-01-10 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

sys.exception() seems like a decent enough trade-off.  I've always disliked the 
abbreviations in "exc_info".  It doesn't feel big enough for a PEP to me.

--

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



[issue46328] add sys.exception()

2022-01-10 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue46321] Don't need delineators on lists

2022-01-09 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

As Dennis points out, this is not a bug, it's already valid Python syntax.

--
nosy: +barry
resolution:  -> not a bug
status: pending -> open

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



[issue46307] string.Template should allow inspection of identifiers

2022-01-08 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

I think you’re right that the iterator API isn’t very helpful.  I also agree 
that you probably really want to answer the “why identifiers are in this 
template?” question.  As for repeats, there’s two ways to think about it.  You 
could return all the identifiers in the order in which they’re found in the 
template (and you can unique-ify them if you want by passing that list to 
set()).  But maybe you don’t really need that either.

get_identifiers() works for me!

On Jan 8, 2022, at 18:51, Ben Kehoe  wrote:
> 
> Ben Kehoe  added the comment:
> 
> Happy to make a PR! In my mind I had been thinking it would be the 
> get_identifiers() method with the implementation above, returning a list.
> 
> As for __iter__, I'm less clear on what that would look like:
> 
> t = string.Template(...)
> for identifier in t:
>  # what would I do here?
>  # would it include repeats if they appear more than once in the template?
> 
> I guess there are two ways to think about it: one is "what identifiers are in 
> this template?" which I think should return a list with no repeats, which I 
> can then iterate over or check if a value is in it. The other is, "what are 
> the contents of the template?" in the style of string.Formatter.parse().
> 
> Given that string.Template is supposed to be the "simple, no-frills" thing in 
> comparison to string.Formatter, I see less use for the latter option.

--

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



[issue46307] string.Template should allow inspection of identifiers

2022-01-08 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

I've never personally needed this, but I could see where it could come in handy.

I wonder if __iter__() would be the right API for that?  I wonder then if we 
should also implement __contains__()?

Would you be interested in creating a PR for the feature?

--

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



[issue46282] print() docs do not indicate its return value

2022-01-07 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

> Barry: The PEP 8 'return None' recommendation could be added to the Reference 
> entry for 'return'.  But I think this should be a separate issue as 1) it is 
> about coding rather than documentation and 2) there is the possible objection 
> that choosing completely explicit 'return None' versus half explicit, half 
> implicit 'return' and the latter versus completely implicit  
> should be left to the style PEP.

I do think it's a question of style.  Section 7.6 of the language reference 
says:

> If an expression list is present, it is evaluated, else None is substituted.

which is the important concept that beginners should learn.

I agree that the admonition in PEP 8 is really trying to say "don't mix 
implicit and explicit return styles".  Implicit None return is fine if all exit 
paths are implicit.  But once you add an explicit value to a return path, all 
return paths should use explicit values, including those that return None.

IME, while I do occasionally encounter push back on this when doing reviews, 
most folks come around to this p.o.v.

--

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



[issue46282] print() docs do not indicate its return value

2022-01-06 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

I think it does a better service to users to explain how Python returns None 
implicitly if a function doesn't have any other explicit return value.  If the 
print() docs had this note, it would be confusing why other similar functions 
don't.

It's also worth explaining that when a function is designed to *explicitly* 
return None in certain cases (e.g. dict.get()) that it shouldn't do so 
implicitly, but should include an explicit `return None` for readability.

--
nosy: +barry

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



[issue46090] C extensions can't swap out live frames anymore

2021-12-23 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue46142] python --help output is too long

2021-12-20 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue22789] Compress the marshalled data in PYC files

2021-10-25 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue45545] chdir __exit__ is not safe

2021-10-25 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

> A LBYL won't always raise errors early as you point out. It will give earlier 
> warnings for a lot of cases, but makes contextlib.chdir usable in less places 
> than os.chdir.
> Some return paths will always be errors, and some will be technically 
> recoverable but too difficult to detect and or fragile. That's why I think 
> any solution should incorporate the `ignore_errors` flag. Its pretty ugly to 
> wrap a context manager in a try: except: just because you were trying to 
> clean up after whatever you were doing but the cwd changed in unexpected 
> ways, maybe out of your control.

How common do you expect such errors to be though?  Do you expect them to be 
more or less common than with os.chdir()?  Do you expect the mitigations to be 
any different than with a failing os.chdir()?

I’ve certainly written a chdir context manager several times and for the use 
cases I care about, I’ve never had such a failure, at least not one that wasn’t 
caused by some other underlying bug, which I was glad wasn’t silenced.

--

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



[issue45545] chdir __exit__ is not safe

2021-10-25 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Does a LBYL strategy actually fix the problem?  E.g. what if the directory gets 
rm'd between __enter__ and __exit__?  Maybe we shouldn't try to be clever at 
all and just leave it to the user to decide what to do, and how to handle any 
chdir-back failures?  Keep it simple?

--

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



[issue45540] module.__package__ and module.__spec__.parent have different semantics

2021-10-21 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Thanks for your comprehensive comments Eric!  While I digest them, my TL;DR is 
that we probably need a PEP to describe everything from the current situation, 
to the the desired end state and migration path.  I'm willing to put that 
together with you and Brett as co-authors if you're amenable.

--

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



[issue45552] Close asyncore/asynchat/smtpd issues and list them here

2021-10-21 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Thank you for doing this work Irit!  Just to point out that anybody who wants a 
modern replacement for smtpd should look at aiosmtpd: 
https://aiosmtpd.readthedocs.io/en/latest/

--

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



[issue45552] Close asyncore/asynchat/smtpd issues and list them here

2021-10-21 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue45545] chdir __exit__ is not safe

2021-10-20 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

> Yes, precisely. Besides being an unreachable long abs path, it might have 
> been deleted since last visited. I’m working on a few more odd test cases.

Ah, the deleted case.  Sounds like LBYL wouldn’t work in that case then. :(

--

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



[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

2021-10-20 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

On Oct 20, 2021, at 08:28, Eric Snow  wrote:
> 
> The only catch I see is where the module's code sets one of the attrs.  Would 
> the proxy (or import machinery) pick those up, or maybe for some of them emit 
> a warning or fail?
> 
> We could also skip the proxy and add the properties to ModuleType directly, 
> no?

My initial idea was to proxy from the ModuleType to the ModuleSpec and I 
started down that path, but hacking in C is much more painful than 
experimenting in Python, so that’s why I did my WIP branch (i.e. just to play 
with the feasibility of it).

Thus I had planned to keep the actual attribute values in the ModuleSpec and 
essentially implement a getattro and setattro in the ModuleType that proxied 
sets and gets to the ModuleSpec.

--

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



[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

2021-10-20 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

On Oct 20, 2021, at 08:18, Eric Snow  wrote:

> The spec identifies how a module should be loaded (or how it was loaded and 
> should be reloaded).  We should be careful to preserve that identify and not 
> invite uses to modify the spec after (or while) the module is loaded.  PEP 
> 451 talks about the difference a little, but I'm pretty sure it came up in 
> more detail in discussions about the PEP at that time.

It’s frankly not good enough to capture the *intent* of these attributes in a 
PEP.  We need to be clear in the documentation about their purpose and we need 
to be clear about when to use or set either the module attribute or the spec 
attribute.  The current situation is ambiguous and possibly misleading.  But 
maybe it’s “just” a documentation issue?

--

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



[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

2021-10-20 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

On Oct 20, 2021, at 11:31, Brett Cannon  wrote:
> 
>> +1 on a proxy (with read-only attrs) for everything but __name__, __file__, 
>> and __path__ (which can all be different than the spec).
> 
> I'm -1 on a proxy as that doesn't simplify the situation. Having (nearly) 
> duplicate attributes is confusing and I have yet to see it benefit anyone.

If we don’t implement a proxy to enforce equivalence, then we shouldn’t say as 
such in the documentation.  And we should be much clearer about what the 
purpose of the spec is versus the module attributes.

--

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



[issue45540] module.__package__ and module.__spec__.parent have different semantics

2021-10-20 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

On Oct 20, 2021, at 11:38, Eric Snow  wrote:
> 
> Regardless, I expect the primary reason __package__ is writable is
> because modules have never had any read-only attrs.

So historical accident mostly.

> The more important question now is, when is __package__ ever modified?
> I can think of 2 cases:
> 
> 1. legacy (pre-451) importers set it when they load the module
> 2. someone wants to customize the import system without writing an importer
> 
> With the latter, specifically they are trying to change how the module
> is reloaded or submodules are imported.  In that case there should
> probably be an explicit way to do so without having to hack the import
> machinery.
> 
> My only concern with any support/encouragement for modifying the spec
> after import is it results in less confidence about how the module was
> imported originally.

I guess a question to answer then is whether we philosophically want the module 
attributes to be equivalent to the spec attributes.  And by equivalent, I mean 
enforced to be exactly so, and thus a proxy.  To me, the duplication is a wart 
that we should migrate away from so there’s only one place for these 
attributes, and that should be the spec.

Here is the mapping we currently describe in the docs:

mod.__name__ === __spec__.name
mod.__package__ === __spec__.parent
mod.__loader__ === __spec__.loader
mod.__file__ === __spec__.origin
mod.__path__ === __spec__.submodule_search_locations
mod.__cached__ === __spec__.cached

But right now, they don’t have to stay in sync, and I don’t think it’s 
reasonable to put the onus on the user to keep them in sync, because it’s 
unclear what code uses which attribute.  Okay, so you can just set them both to 
be safe, but then you can’t do that with __spec__.parent/__package__

This is what leads me to think that having a proxy to keep them in sync and 
relaxing the read-only restriction is the path forward, even if writing 
__package__ doesn’t make sense.  It also seems like the easier way to keep 
backward compatibility, rather than enforcing read-only on __package__ to match 
__spec__.parent.

So the question is less about whether this is useful than whether it will break 
things if they write to it.

--

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



[issue45545] chdir __exit__ is not safe

2021-10-20 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Does this mean that CWD could be in a directory that you couldn't chdir() back 
into?

--
nosy: +barry

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



[issue35673] Loader for namespace packages

2021-10-20 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

On Oct 20, 2021, at 11:27, Brett Cannon  wrote:
> 
>> That should probably be a separate issue/PR in either case.
> 
> https://bugs.python.org/issue38782 and I was trying to rope you into doing 
> the work. 

Ha!  You should have nosied me then :D - but anyway I’m following that ticket 
now so we’ll see.

--

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



[issue35673] Loader for namespace packages

2021-10-20 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


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

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



[issue38782] Convert importlib.abc to use typing.Protocol

2021-10-20 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue35673] Loader for namespace packages

2021-10-20 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:


New changeset 876fc7fcec9a79a11546b7588d3683a5ccb4d31c by Barry Warsaw in 
branch 'main':
bpo-35673: Add a public alias for namespace package __loader__ attribute 
(#29049)
https://github.com/python/cpython/commit/876fc7fcec9a79a11546b7588d3683a5ccb4d31c


--

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



[issue45540] module.__package__ and module.__spec__.parent have different semantics

2021-10-20 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +brett.cannon, eric.snow

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



[issue45540] module.__package__ and module.__spec__.parent have different semantics

2021-10-20 Thread Barry A. Warsaw


New submission from Barry A. Warsaw :

TL;DR module.__spec__.parent is read-only but module.__package__ is r/w despite 
documentation that implies that these two attributes should be identical, and 
various issues that focus on migrating from direct module attributes to 
ModuleSpec attributes.

bpo-33277 and bpo-21762

Maybe we should relax the restriction on module.__spec__.parent so that it's 
writeable just like module.__package__.

See also: 

https://docs.python.org/3/reference/import.html?highlight=__loader__#package__

https://docs.python.org/3/library/types.html?highlight=__loader__#types.ModuleType.__package__

--
components: Interpreter Core
messages: 404500
nosy: barry
priority: normal
severity: normal
status: open
title: module.__package__ and module.__spec__.parent have different semantics
versions: Python 3.11

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



[issue42092] test_host_resolution_bad_address does not always fail as expected

2021-10-20 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
pull_requests: +27351
pull_request: https://github.com/python/cpython/pull/29085

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



[issue42092] test_host_resolution_bad_address does not always fail as expected

2021-10-20 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

Woot!  I finally figured out the problem and how to fix it.  It has nothing to 
do with Python and everything to do with AT  They run a service called DNS 
Error Assist, quoting:

"Sometimes we enter a wrong search word, or a wrong web address, or maybe the 
website we want is no longer in service. If this happens, the DNS Error Assist 
service automatically searches for similar or related terms and presents you 
some results that may be useful for you. Otherwise, you’ll get a “No results 
found” error message."

Turning this off is buried in AT's site.  I found some outdated 
recommendations on the web, but here's what worked for me (as of the date of 
this comment).

Log in to your AT portal, search for "Privacy" and click on the link that 
says "Privacy in Support".  This takes you to a page that describes AT's 
privacy policies, and gives you a link to "Go" to your privacy settings.

>From there you should see two sections, one that says "Control how we 
>communicate with you" and one that says "Control how we use your data".  
>Select DNS Error Assist and disable that.  You'll need to wait a few minutes 
>for it to take effect, but then you'll get none of those bogus resolutions.

While you're at it, you might want to review your other privacy settings.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions:  -Python 3.10, Python 3.7, Python 3.8, Python 3.9

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



[issue33277] Deprecate __loader__, __package__, and __cached__ on modules

2021-10-19 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
keywords: +patch
pull_requests: +27347
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/29078

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



[issue35673] Loader for namespace packages

2021-10-19 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

I don't know.  What benefit would be gained?  That should probably be a 
separate issue/PR in either case.

--

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



[issue45493] str() and repr() of enum different in Python 3.11 from Python <= 3.10

2021-10-19 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

I can see why Ethan might be overwhelmed by reverting this change.  I tried to 
merge in his branch but failed, so I'm chucking that work and will try again.

--

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



[issue35673] Loader for namespace packages

2021-10-18 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Since the documentation problem reported here has since been fixed, and really 
all that's left is to expose NamespaceLoader publicly and register it with the 
abc, this is technically a new feature so it can't be backported.  Thus, 
targeting only 3.11.

--
versions:  -Python 3.10, Python 3.9

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



[issue35673] Loader for namespace packages

2021-10-18 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

First crack at a PR for this issue.

--
keywords: +needs review -patch

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



[issue35673] Loader for namespace packages

2021-10-18 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


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

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



[issue35673] Loader for namespace packages

2021-10-18 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


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

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



[issue35673] Loader for namespace packages

2021-10-18 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

I'm going to take a look at this during the Python core sprint.

--
assignee:  -> barry

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



[issue45493] str() and repr() of enum different in Python 3.11 from Python <= 3.10

2021-10-18 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

This doesn't seem right, given that PEP 663 has not been approved by the SC yet:

3.9.7 (default, Oct 13 2021, 06:45:31) 
[Clang 13.0.0 (clang-1300.0.29.3)]
ABC.a ABC.b ABC.c ABC.a 
|main=|@presto[~/projects/python/cpython:1058]% python3.10 /tmp/foo.py 
3.10.0 (default, Oct 13 2021, 06:45:00) [Clang 13.0.0 (clang-1300.0.29.3)]
ABC.a ABC.b ABC.c ABC.a 
|main=|@presto[~/projects/python/cpython:1059]% ./python.exe /tmp/foo.py 
3.11.0a1+ (heads/main:6a533a4238, Oct 18 2021, 15:30:20) [Clang 13.0.0 
(clang-1300.0.29.3)]
a b c a ABC.a

In 3.10, the behavior was reverted back to 3.9, so it makes sense that those 
two have the same output.  Python 3.11 should as well, for now at least, until 
the SC approves PEP 663

--
nosy: +barry, ethan.furman

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



[issue21736] Add __file__ attribute to frozen modules

2021-10-18 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Weird.  PR 28655 is merged on GH, but still shows open on this bpo ticket.

--

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



[issue37722] imaplib crashes when trying to read a letter from an imap server imaps.почта.рус

2021-10-18 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy:  -barry

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



[issue45506] Out of source tree builds failing on main - test_importlib others unreliable

2021-10-18 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

FWIW, Greg's test case does not fail for me with 6a533a4238

--
nosy: +barry

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



[issue45324] The frozen importer should capture info in find_spec().

2021-09-29 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue45020] Freeze all modules imported during startup.

2021-09-27 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-16 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

On Sep 16, 2021, at 00:36, STINNER Victor  wrote:
> 
> The commit title is wrong, the default "big" not sys.byteorder:
> 
>int.to_bytes(length=1, byteorder='big', *, signed=False)
>int.from_bytes(bytes, byteorder='big', *, signed=False)

Oops

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-15 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


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

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-15 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:


New changeset 07e737d002cdbf0bfee53248a652a86c9f93f02b by Barry Warsaw in 
branch 'main':
bpo-45155 : Default arguments for int.to_bytes(length=1, 
byteorder=sys.byteorder) (#28265)
https://github.com/python/cpython/commit/07e737d002cdbf0bfee53248a652a86c9f93f02b


--

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



[issue45202] Add 'remove_barry_from_BDFL' future to revert effects of 'from __future__ import barry_as_FLUFL'

2021-09-15 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

This bug made my day! :-D

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-14 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

"big" by default

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-13 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

On Sep 13, 2021, at 22:12, Vedran Čačić  wrote:
> 
> 
> Vedran Čačić  added the comment:
> 
> I'd say yes. Of course, one way to ascertain that would be to conduct a valid 
> pool. ;-)

People can always comment otherwise in the Discourse thread.

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-13 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

On Sep 13, 2021, at 13:39, Vedran Čačić  wrote:
> 
> The poll is invalid, since the option that most people want is deliberately 
> not offered.

*Is* there an option that most people want?

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-13 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

On Sep 13, 2021, at 13:38, STINNER Victor  wrote:
> It seems like your proposal is mostly guided by: convert an int to a byte 
> (bytes string of length 1). IMO this case is special enough to justify the 
> usage of a different function.

Like bchr() ? 

> What if people expect int.to_bytes() always return a single byte, but then 
> get two bytes by mistake?
> 
> ch = 256
> byte = ch.to_bytes()

The OverflowError you’ll get seems reasonable.

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-13 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

> I'd probably say "In the face of ambiguity, refuse the temptation to guess".
> 
> As there's disagreement about the 'correct' default, make it None and require 
> either "big" or "little" if length > 1 (the default).

Jelle suggested that over in Discourse, and I’m not opposed, but it does mean 
that there’s no natural default for byteorder in int.from_bytes().

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-13 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

I created a Discourse poll: 
https://discuss.python.org/t/what-should-be-the-default-value-for-int-to-bytes-byteorder/10616

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-13 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

That’s okay, Brandt’s improved sys.byteorder is fastest .

% ./python.exe -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "little")'
200 loops, best of 11: 94.6 nsec per loop
% ./python.exe -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "big")'
200 loops, best of 11: 97.8 nsec per loop
% ./python.exe -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10)'
500 loops, best of 11: 79.1 nsec per loop

On Sep 12, 2021, at 04:20, Raymond Hettinger  wrote:
> 
> Raymond Hettinger  added the comment:
> 
> Interestingly, "little" is faster than "big".
> 
> $ python3.10 -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "little")'
> 500 loops, best of 11: 82.7 nsec per loop
> $ python3.10 -m timeit -r11 -s 'x=3452452454524' 'x.to_bytes(10, "big")'
> 500 loops, best of 11: 90.6 nsec per loop
> 
> --
> 
> ___
> Python tracker 
> <https://bugs.python.org/issue45155>
> ___

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-10 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

Petr Viktorin  added the comment:
> 
> Exactly, a platform-dependent default is a bad idea. A default allows using 
> the function without the code author & reviewer even being *aware* that there 
> is a choice, and that is dangerous.

I’m not convinced.  I’m more concerned with the obscurity of the API.  If I saw 
its use in some code I was reviewing, I’d look it up, and then I’d know exactly 
what it was doing.

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-10 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

On Sep 10, 2021, at 04:06, STINNER Victor  wrote:
> 
> If the intent is to create a bytes string of length 1, I'm not sure that 
> "re-using" this existing API for that is a good idea.

Why not?  It seems an obvious and simple convenience.

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-10 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

Just to point out, struct module also uses “native” (i.e. system) byte order by 
default.  Any choice other than that for to_bytes() seems both arbitrary and 
inconsistent.

> On Sep 10, 2021, at 00:48, Petr Viktorin  wrote:
> 
> Exactly, a platform-dependent default is a bad idea. A default allows using 
> the function without the code author & reviewer even being *aware* that there 
> is a choice, and that is dangerous.

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-09 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

For the common case where you’re using all defaults, it won’t matter.  
byteorder doesn’t matter when length=1.

> On Sep 9, 2021, at 18:12, Raymond Hettinger  wrote:
> 
> 
> Raymond Hettinger  added the comment:
> 
> Perhaps instead of the system byte ordering, choose one for the default so 
> that default encoding/decoding will work cross platform.  I think "little" is 
> the most common (intel and arm).

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-09 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

> Ah, signed=False by default, so (128).to_bytes() will work. But I still worry 
> that it can provoke writing more errorprone code.

Can you elaborate on that?  Obviously no existing code will change behavior.  I 
really don’t expect people to write `(128).to_bytes(signed=True)` by accident.

--

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-09 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
keywords: +patch
pull_requests: +26685
pull_request: https://github.com/python/cpython/pull/28265

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



[issue45155] Add default arguments for int.to_bytes()

2021-09-09 Thread Barry A. Warsaw


New submission from Barry A. Warsaw :

In the PEP 467 discussion, I proposed being able to use

>>> (65).to_bytes()
b'A'

IOW, adding default arguments for the `length` and `byteorder` arguments to 
`int.to_bytes()`

https://mail.python.org/archives/list/python-...@python.org/message/PUR7UCOITMMH6TZVVJA5LKRCBYS4RBMR/

It occurs to me that this is (1) useful on its own merits; (2) easy to do.  So 
I've done it.  Creating this bug so I can link a PR against it.

--
components: Interpreter Core
messages: 401524
nosy: barry
priority: normal
severity: normal
stage: patch review
status: open
title: Add default arguments for int.to_bytes()
versions: Python 3.11

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



[issue44616] Incorrect tracing for "except" with variable

2021-07-15 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Thanks Ned.  Seems you might be right.  I thought I'd done a clean test, but in 
any event, I just pulled 3.10 head and verified that it's producing 100% 
coverage.  Thanks all for the fix!

--
resolution:  -> fixed
status: open -> closed

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



[issue44616] Incorrect tracing for "except" with variable

2021-07-14 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

I just retested my test case (see the coveragepy link below) with Python 3.10 
git head and coveragepy git head, and I'm still seeing the misses only in 
Python 3.10:

-- coverage: platform darwin, python 3.10.0-beta-4 ---
Name  Stmts   Miss Branch BrPart  Cover   Missing
-
flufl/lock/__init__.py5  0  0  0   100%
flufl/lock/_lockfile.py 253  0 80  399%   412->415, 
418->420, 535->exit
-


The lines in question:

if is_locked:
try:
os.unlink(self._lockfile)
except OSError as error:
if error.errno not in ERRORS:
raise
# Remove our claim file.
try:
os.unlink(self._claimfile)
except OSError as error:
if error.errno not in ERRORS:
raise

I'm not sure whether coveragepy needs to be updated or whether there are other 
lurking bugs in Python 3.10.  I'm reopening this issue until this is resolved.

--
resolution: fixed -> 
status: closed -> open

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



[issue44616] Incorrect tracing for "except" with variable

2021-07-12 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Pablo, this is triggered by my bug report here: 
https://github.com/nedbat/coveragepy/issues/1187

I tested this again today with the 3.10 git head and still got the coverage 
misses.  Happy to try any other combinations.

--

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



[issue44613] Make importlib.metadata non-provisional in Python 3.10

2021-07-12 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Jason, I think the question you raise re: accelerated deprecation, is probably 
a RM or SC question.  I'll nosy in Pablo and see if he has a strong opinion.

--
nosy: +pablogsal

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



[issue44613] Make importlib.metadata non-provisional in Python 3.10

2021-07-12 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


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

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



[issue44613] Make importlib.metadata non-provisional in Python 3.10

2021-07-12 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:


New changeset 7223ce3b3f50ec8a825e317437ea0359b6ad6856 by Miss Islington (bot) 
in branch '3.10':
bpo-44613: Make importlib.metadata non-provisional (GH-27101) (#27106)
https://github.com/python/cpython/commit/7223ce3b3f50ec8a825e317437ea0359b6ad6856


--

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



[issue44613] Make importlib.metadata non-provisional in Python 3.10

2021-07-12 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:


New changeset f6954cdfc50060a54318fb2aea4d80408381243a by Barry Warsaw in 
branch 'main':
bpo-44613: Make importlib.metadata non-provisional (#27101)
https://github.com/python/cpython/commit/f6954cdfc50060a54318fb2aea4d80408381243a


--

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



[issue44616] Incorrect tracing for "except" with variable

2021-07-12 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue44613] Make importlib.metadata non-provisional in Python 3.10

2021-07-12 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


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

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



[issue44613] Make importlib.metadata non-provisional in Python 3.10

2021-07-12 Thread Barry A. Warsaw


New submission from Barry A. Warsaw :

As discussed with Jason, importlib.metadata will be made non-provisional in 
3.10.  I have a PR in the works for this.

--
assignee: barry
components: Documentation
messages: 397344
nosy: barry, jaraco
priority: normal
severity: normal
status: open
title: Make importlib.metadata non-provisional in Python 3.10
versions: Python 3.10, Python 3.11

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



[issue33025] urlencode produces bad output from ssl.CERT_NONE and friends that chokes decoders

2021-06-29 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue43945] [Enum] standardize format() behavior

2021-06-29 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

2021-06-28 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue44498] add deprecation warnings for asynchat, asyncore and smtpd

2021-06-24 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:


New changeset 8488b85c6397fe58f17fc00e047044c959ac0b04 by Barry Warsaw in 
branch 'main':
bpo-44498: Issue a deprecation warning on asynchat, asyncore and smtpd import 
(#26882)
https://github.com/python/cpython/commit/8488b85c6397fe58f17fc00e047044c959ac0b04


--

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



[issue44498] move deprecated asynchat, asyncore and smtpd from the stdlib to test.support

2021-06-23 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
pull_requests: +25459
pull_request: https://github.com/python/cpython/pull/26882

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



[issue44498] move deprecated asynchat, asyncore and smtpd from the stdlib to test.support

2021-06-23 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

+1 for removal

--
nosy: +barry

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



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

2021-05-21 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue43817] Add typing.get_annotations()

2021-04-16 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue37741] importlib.metadata docs not showing up in the module index

2021-04-14 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

@jaraco beat me to it.  PRs approved!

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

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



[issue37741] importlib.metadata docs not showing up in the module index

2021-04-14 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

I'd still like to.  I'm also happy to review any PRs if someone beats me to it.

--

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



[issue42728] Typo in documentation: importlib.metadata

2020-12-31 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Thanks for the report and fix!

--
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.8, Python 3.9

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



[issue42728] Typo in documentation: importlib.metadata

2020-12-31 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry, jaraco

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



[issue28468] Add platform.freedesktop_os_release()

2020-11-30 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

This issue was brought to the Python Steering Council, and we deliberated it at 
today's SC meeting.  With a vote of 4 approvals and one abstention, we have 
approved the addition of this API.

--
nosy: +barry

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



[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

2020-10-26 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.8, Python 3.9

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



[issue42155] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

2020-10-26 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


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

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



[issue42155] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

2020-10-26 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Hi Serhiy.  I believe this is a duplicate of bpo-30681 which is active and has 
a good PR IMHO.  The only hold up is whether to backport that PR to 3.9 and 
3.8.  See the bug and PR for details.

--
resolution:  -> duplicate
superseder:  -> email.utils.parsedate_to_datetime() should return None when 
date cannot be parsed

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



[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

2020-10-23 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

Aside: I noticed that on _parseaddr.py:68, there's a bare `return`.  That 
should really be `return None` (EIBTI).  Can you fix that in your PR?

I think it's confusing to raise both TypeError and ValueError.  I suggest we 
check the `None` return from _parsedate_tz() and raise ValueError explicitly in 
that case, avoiding the implicit TypeError on the failing tuple unpack.

+1 on removing the mention of returning None from the documentation.  Then with 
the above, it would document raising ValueError on invalid date input.

As for backporting, I'm nosing Ned and Łukasz to weigh in.  Given that the 
patch is adding a new defect class (which it should), this won't break existing 
code, but it does mean that existing code would have different semantics 
depending on the patch version release of 3.9, 3.8, and 3.7.  I'm not 
completely comfortable with that, but let's see what the RMs say.  I guess I'm 
currently -0 on backporting.

--
nosy: +lukasz.langa, ned.deily

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



[issue42129] Support resources in namespace packages

2020-10-23 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue38486] Dead links in mailbox doc

2020-10-22 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Thanks for the PR @ZackerySpytz - this has landed in git head and is currently 
being backported to 3.9 and 3.8 (3.7 is in security-fix only mode).

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7

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



[issue38486] Dead links in mailbox doc

2020-10-22 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
versions: +Python 3.10

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



[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

2020-10-22 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

@sim0n - I added a comment to your open PR.

My main question for the rest of the group is whether we can and should 
backport this.  Given the new defect class being introduced, it seems like this 
should only land in 3.10.  Thoughts?

--

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



[issue31522] _mboxMMDF.get_string() fails to pass param to get_bytes()

2020-10-22 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Actually, it looks to me like the PR *does* include unittests, and I see them 
in the repo, so I'm closing this bug.

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

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



[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

2020-10-22 Thread Barry A. Warsaw


Change by Barry A. Warsaw :


--
nosy: +barry

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



[issue35181] Doc: Namespace Packages: Inconsistent documentation of __loader__ being None

2020-10-21 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

@maggyero - I haven't merged PR 10016, but I left some additional comments.  
Are you still interested in shepherding this PR?

--

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



[issue35181] Doc: Namespace Packages: Inconsistent documentation of __loader__ being None

2020-10-21 Thread Barry A. Warsaw


Barry A. Warsaw  added the comment:

Apologies for the long delay in reviewing this bug.  I'm looking at it now, 
however since Python 3.7 is in security-only mode, this will only apply to 
3.10, 3.9, and 3.8.

--
versions: +Python 3.10, Python 3.9 -Python 3.7

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



  1   2   3   4   5   6   7   8   9   10   >