[issue44258] Support PEP 515 for Fraction's initialization from string

[Sergey B Kirpichev]

New submission from Sergey B Kirpichev :

Right now:
>>> from fractions import Fraction as F
>>> F(1_2_3, 3_2_1)
Fraction(41, 107)

but

>>> F('1_2_3/3_2_1')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/sk/src/cpython/Lib/fractions.py", line 115, in __new__
raise ValueError('Invalid literal for Fraction: %r' %
ValueError: Invalid literal for Fraction: '1_2_3/3_2_1'

or even this (should be consistent with int constructor, isn't?):
>>> F('1_2_3')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/sk/src/cpython/Lib/fractions.py", line 115, in __new__
raise ValueError('Invalid literal for Fraction: %r' %
ValueError: Invalid literal for Fraction: '1_2_3'

Tentative patch attached.  Let me know if this does make sense as a PR.

--
components: Library (Lib)
files: fractions-from-str.diff
keywords: patch
messages: 394633
nosy: Sergey.Kirpichev
priority: normal
severity: normal
status: open
title: Support PEP 515 for Fraction's initialization from string
versions: Python 3.11
Added file: https://bugs.python.org/file50069/fractions-from-str.diff

___
Python tracker 

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

[issue44256] _functools._lru_list_elem is exposed unintentionally.

[Inada Naoki]

Inada Naoki  added the comment:


New changeset 28be3191a9db2769ed05e55c6bcbccdd029656dd by Inada Naoki in branch 
'main':
bpo-44256: Do not expose _functools._list_elem_type (GH-26416)
https://github.com/python/cpython/commit/28be3191a9db2769ed05e55c6bcbccdd029656dd


--

___
Python tracker 

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

[issue44256] _functools._lru_list_elem is exposed unintentionally.

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +25013
pull_request: https://github.com/python/cpython/pull/26418

___
Python tracker 

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

[issue43654] IDLE: Applying settings disables tab completion

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Tal, I think you had the right solution the first time.  To me, tab is (should 
be) a fixed key, and the event added just once, like the other fixed keys.  I 
am quite surprised that it isn't.  Please revise or make a new patch to remove 
it from both configkeys.def and config.py.

Even if I agreed with unfixing other keys, only <> would need 
rebinding, not an arbitrary subset of the fixed keys.  We mostly did away with 
treating some features differently; what remains was mostly an expedient to get 
a too-big patch merged.  I meant and still mean to finish the job.

--

___
Python tracker 

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

RE: learning python ...

[Avi Gross via Python-list]

HomeWork,

Nobody is suggesting that you change your attitude because of one obstacle.

But what if EVERYBODY here gives you similar feedback that python IS the way it 
is irrelevant of what other language designers have chosen or you expect?

Even if you propose a change that might be nice but it would break lots of 
existing programs, do you think it likely it would be done and time soon when 
the 2.x to 3.x transition has been so traumatic to some?

The reality is that you are here as a potential USER of Python or some other 
language and probably have not read enough about Python methods and features to 
be able to make the judgements you make. You do not seem able to handle some 
aspects of abstraction such as why you might want to write code that allows you 
to make some arbitrary changes. Wait till you find out how you can use Python 
to change the meaning of "+" to mean "-"  or anything else you want. But that 
same feature might let you redefine addition of two objects of a string-like 
nature to mean concatenation with a comma and space between them or whatever.

Clearly I can now conclude it is not worth continuing to do more discussion 
with you. I am not learning anything and neither are you, apparently. So you go 
do whatever it is you want and I will ignore and do something potentially of 
minimal use.

I have plenty of things in Python I am not thrilled with at times but I see 
that it is what it is. So, I use other languages for places where I see them as 
better or easier. But even when I do not love some feature, I do generally know 
why it is like it is and that generally someone else wanted it that way. It 
might be for efficiency or because it was easier to program it that way or even 
that my preferred way has problems I was not aware of. But generally, most 
languages have been fairly well thought-out with specific ideas in mind and are 
in many ways FINISHED albeit can often grow later.

-Original Message-
From: Python-list  On 
Behalf Of hw
Sent: Thursday, May 27, 2021 2:30 PM
To: python-list@python.org
Subject: Re: learning python ...


When the idea is to learn something, it's not exactly helpful to abandon that 
idea when encountering the first obstacle or when someone tells you you don't 
like it as much as they do ...

On 5/25/21 7:56 AM, Avi Gross via Python-list wrote:
> I have studied many programming languages and am amused when people attack 
> python as if every other language is somehow more optimal.
> 
> Cameron and others have provided examples but look at positives AND negatives.
> 
> Yes code like: num = int(num)
> 
> does look a tad off as it reuses the same name for something that is actually 
> in many ways different. You could easily use a new name. But then you would 
> have TWO variables in your name space and the old one would not be garbage 
> collected unless you explicitly removed it. If you follow this path, would 
> you suggest not writing: X = X + 1 either?
> 
> It is actually a fairly common practice in many languages to have code like 
> this:
> 
> Var = read in something from a file and make some structure like a 
> data.frame Var = remove some columns from the above thing pointed to 
> by Var Var = make some new calculated columns ditto Var = remove some 
> rows ...
> Var = set some kind of grouping on the above or sort it and so on.
> 
> As you go along you may keep transforming but have no need for earlier 
> results, just the new and improved one. So why keep changing names? Some 
> languages support not having any names for intermediate results by using 
> nested function calls or pipelines.
> 
> The reality is that most languages have a series of what I loosely would call 
> environments or name tables and as they run, new ones regularly get created 
> and removed and even the order of them may change. The algorithm for 
> searching for a name varies and can be in some sense linear or more complex. 
> When looking in context for a function name, you may follow a different trail 
> or the same one as for a variable holding a string and in some 
> implementations the same name shadows and in others does not. Wait till you 
> try to figure out the diamond pattern of inheritance when you create classes 
> that depend on multiple other classes ad nauseum and you try to call a method 
> and it tries to find the one you wanted by searching backwards in an 
> interesting way. Many other languages decided to just not allow multiple 
> inheritance!
> 
> How can you write a recursive function without this kind of variable 
> shadowing? Each invocation of a function places the internal namespace in 
> front of the parent so the meaning of a variable name used within is always 
> backed by  all the iterations before it. But with some kinds of closures, a 
> function may be gone and yet variables it had within it persists. Lots of odd 
> examples more make this a complex set of CHOICES.
> 
> So what if you suggest we allow re-use of names but WARN 

Re: name for new Enum decorator

[2QdxY4RzWzUUiLuE]

On 2021-05-27 at 20:23:29 -0700,
Regarding "name for new Enum decorator,"
Ethan Furman  wrote:

> Greetings!
> 
> The Flag type in the enum module has had some improvements, but I find it
> necessary to move one of those improvements into a decorator instead, and
> I'm having a hard time thinking up a name.
> 
> What is the behavior?  Well, a name in a flag type can be either canonical
> (it represents one thing), or aliased (it represents two or more things).
> To use Color as an example:
> 
> class Color(Flag):
> RED = 1# 0001
> GREEN = 2  # 0010
> BLUE = 4   # 0100
> PURPLE = RED | BLUE# 0101
> WHITE = RED | GREEN | BLUE # 0111
> 
> The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE are
> aliases for certain flag combinations.  But what if we have something like:
> 
> class Color(Flag):
> RED = 1# 0001
> BLUE = 4   # 0100
> WHITE = 7  # 0111
> 
> As you see, WHITE is an "alias" for a value that does not exist in the Flag
> (0010, or 2).  That seems like it's probably an error.  But what about this?
> 
> class FlagWithMasks(IntFlag):
> DEFAULT = 0x0
> 
> FIRST_MASK = 0xF
> FIRST_ROUND = 0x0
> FIRST_CEIL = 0x1
> FIRST_TRUNC = 0x2
> 
> SECOND_MASK = 0xF0
> SECOND_RECALC = 0x00
> SECOND_NO_RECALC = 0x10
> 
> THIRD_MASK = 0xF00
> THIRD_DISCARD = 0x000
> THIRD_KEEP = 0x100
> 
> Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are
> aliasing values that don't exist, but it seems intentional and not an error.
> 
> So, like the enum.unique decorator that can be used when duplicate names
> should be an error, I'm adding a new decorator to verify that a Flag has no
> missing aliased values that can be used when the programmer thinks it's
> appropriate... but I have no idea what to call it.
> 
> Any nominations?

Exhaustive?

I see two qualitatively different kinds of enums:  those that can/should
be "or"ed together (e.g., RED, GREEN) and those that cannot (e.g.,
FIRST_ROUND, FIRST_CEIL, and FIRST_TRUNC).  The idea of a "missing"
value doesn't seem to apply to the second type (because defining
FIRST_TRUNC as FIRST_ROUND | FIRST_CEIL is nonsensical).  I don't quite
know what that may or may not suggest as far as names go, but it may
give someone else an idea.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue44257] typo and verbous grammar in the grammar spec

[ShinWonho]

Change by ShinWonho :


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

___
Python tracker 

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

[issue44257] typo and verbous grammar in the grammar spec

[ShinWonho]

New submission from ShinWonho :

In Python Language Reference 10.Full Grammar Specification
typo: assigment_expression
verbous grammar: expressions and star_expression

--
assignee: docs@python
components: Documentation
messages: 394630
nosy: docs@python, orangebana15
priority: normal
severity: normal
status: open
title: typo and verbous grammar in the grammar spec
type: enhancement
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

name for new Enum decorator

[Ethan Furman]

Greetings!

The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements 
into a decorator instead, and I'm having a hard time thinking up a name.


What is the behavior?  Well, a name in a flag type can be either canonical (it represents one thing), or aliased (it 
represents two or more things).  To use Color as an example:


class Color(Flag):
RED = 1# 0001
GREEN = 2  # 0010
BLUE = 4   # 0100
PURPLE = RED | BLUE# 0101
WHITE = RED | GREEN | BLUE # 0111

The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE are aliases for certain flag combinations.  But 
what if we have something like:


class Color(Flag):
RED = 1# 0001
BLUE = 4   # 0100
WHITE = 7  # 0111

As you see, WHITE is an "alias" for a value that does not exist in the Flag (0010, or 2).  That seems like it's probably 
an error.  But what about this?


class FlagWithMasks(IntFlag):
DEFAULT = 0x0

FIRST_MASK = 0xF
FIRST_ROUND = 0x0
FIRST_CEIL = 0x1
FIRST_TRUNC = 0x2

SECOND_MASK = 0xF0
SECOND_RECALC = 0x00
SECOND_NO_RECALC = 0x10

THIRD_MASK = 0xF00
THIRD_DISCARD = 0x000
THIRD_KEEP = 0x100

Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are aliasing values that don't exist, but it seems 
intentional and not an error.


So, like the enum.unique decorator that can be used when duplicate names should be an error, I'm adding a new decorator 
to verify that a Flag has no missing aliased values that can be used when the programmer thinks it's appropriate... but 
I have no idea what to call it.


Any nominations?

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

[issue44256] _functools._lru_list_elem is exposed unintentionally.

[Inada Naoki]

Change by Inada Naoki :


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

___
Python tracker 

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

Re: learning python ...

[Christian Gollwitzer]

Am 25.05.21 um 06:08 schrieb hw:

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

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

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


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




Yes, it does. It is a common pitfall for newbie Python programmers.

def f(a):
a.append(2)

l=[1, 2, 3]

f(l)
print(l)


==> [1, 2, 3, 2]

The strange thing, coming from a different language, is the apparent 
difference, if instead of a list, you pass an integer:


def f(a):
a=5

l=3

f(l)
print(l)

> 3

Here, the "l" is not changed. The reason is that the statement "a=5" 
does NOT modify the object in a, but instead creates a new one and binds 
it to a. l still points to the old one. Whereas a.append() tells the 
object pointed to by a to change.


Christian

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

Re: learning python ...

[Michael F. Stemper]

On 27/05/2021 16.13, Christian Gollwitzer wrote:

Am 25.05.21 um 06:08 schrieb hw:

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

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

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


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


The strange thing, coming from a different language, is the apparent 
difference, if instead of a list, you pass an integer:


def f(a):
 a=5

l=3

f(l)
print(l)

> 3

Here, the "l" is not changed. The reason is that the statement "a=5" 
does NOT modify the object in a, but instead creates a new one and binds 
it to a. l still points to the old one. Whereas a.append() tells the 
object pointed to by a to change.


What was fun in Fortran was that you could do the following:

  CALL SS(3)
  PRINT *, 3
  END
  SUBROUTINE SS(K)
  K = 5
  RETURN
  END

The output of this gem would be 5, at least though Fortran 77. It was
call by reference, even for constants. (Every manual said not to do
this, of course.)

--
Michael F. Stemper
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.
--
https://mail.python.org/mailman/listinfo/python-list

[issue44253] tkinter searches for tk.tcl in wrong directory

[Adam Stewart]

Adam Stewart  added the comment:

I think I FINALLY figured out the problem. We were setting `TCLLIBPATH` to 
`/lib/tk8.6` when it should be `/lib`. With this change, 
tkinter seems to work for me. Thanks for all of your help!

--

___
Python tracker 

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

[issue44248] copy.deepcopy calls objdect's __deepcopy__ with incorrect argument

[Zachary Ware]

Zachary Ware  added the comment:

Actually, looking into the implementation a bit, I can say there is definitely 
no bug here.  Line 153 basically works out to `y = x.__deepcopy__(memo)`, which 
is how the `__deepcopy__` method is documented[1] to be called.  Calling 
`copier(x)` instead would cause serious problems when a well-behaved 
`__deepcopy__` method then tries to call `deepcopy(self.some_attribute, memo)`.

As such, I'm closing this issue as "not a bug".

[1] https://docs.python.org/3/library/copy.html (see the last paragraph)

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

[issue44256] _functools._lru_list_elem is exposed unintentionally.

[Inada Naoki]

Inada Naoki  added the comment:

Ref: GH-23405.

--

___
Python tracker 

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

[issue44256] _functools._lru_list_elem is exposed unintentionally.

[Inada Naoki]

New submission from Inada Naoki :

_lru_list_elem is internal data strucuture. It is intended to be used only in 
_lru_cache_wrapper.
Until Python 3.9, it is not exposed. But it is exposed by dd3912 accidentally.

--
components: Extension Modules
keywords: 3.10regression
messages: 394626
nosy: methane
priority: normal
severity: normal
status: open
title: _functools._lru_list_elem is exposed unintentionally.
type: behavior
versions: Python 3.10, Python 3.11

___
Python tracker 

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

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

[Anthony Sottile]

Anthony Sottile  added the comment:

> Which types are sneaky and look like built-in types but do not act like them?

well for starters, there's the tuple subclass which pretends to be a dict.  but 
it violates substitutability for both `tuple` and `Mapping` so it's not useful 
in either contexts.  mypy complains about incorrect types in overrides for 
both.  the worst part of this is that the `__getitem__` moves from O(1) to O(N) 
(in some private code this makes importlib.metadata on 3.10 _10x slower than on 
3.9_).  next there's the `EntryPoints` tuple subclass which looks like a tuple 
but doesn't at all act like one (__getitem__ fails substitutability for 
example) -- this is an api break with 3.9 which returned a `list` (can't 
`.sort()` `.extend(...)`, etc. any more)

> Given that backports are available

I don't think this is appropriate.  re-introducing a backport brings in a tree 
of dependencies that have been shaky at best with backward compatibility.  in 
other words, using standard library importlib.metadata provides significantly 
improved compatibility and stability over the moving target backport (and its 
tree of dependencies, zipp being the one that breaks the most often from 
experience).  you'll notice I closed the flake8 PRs specifically because I 
didn't want to reintroduce the backport.  This backport also globally 
monkeypatches the import machinery breaking any other consumer as well -- in a 
tool as popular as flake8 I can't really make that global mutation decision for 
all of the other consumers.

> The typing issues

these were *trivially solved* by a dictionary comprehension using 
`entrypoint.name` -- it really did not need a full rework and break of the api 
to solve (could have just deprecated the `__iter__` which I actually suggested 
on the *original implementation* way back in 3.8)

> The new APIs are not only easier to describe with types

the types describing the new apis require *significant* `# type: ignore`s to 
pass mypy because they violate basic substitutability.  they also cannot be 
used in any of the contexts they were appropriate for in <3.10 (Dict[str, 
List[EntryPoint]] or List[Entrypoint] depending on the api).

> I'm not aware of a single breakage.

I'm sorry but you have to have realized from the many issues on 
importlib-metadata or the many issues linking to your deprecation issue that 
there is significant toil caused directly by your change.  cpython is meant to 
be a stable substrate to build upon, please do not force the community to 
shoulder the burden of your poor api decisions.

> even without requiring an updated importlib_metadata backport.

your proposed change introduced a different, unrelated package.  not without 
its own maintenance problems (an additional dependency that has to ~work 
indefinitely, a hack at best to support this breaking change)

> Given the amount of adoption already, reverting these changes is likely to 
> cause more disruption than moving forward with them.

I disagree, bigger things have been reverted (see: __future__.annotations)

>  So far, the only example presented above appears contrived and not an actual 
> concern

I promise you this is not a contrived case, if you look at your issue tracker 
it has been reported before and by others.  For every issue reported there's 
likely tens or hundreds of others which are not reported.

> It's common for Python minor releases to introduce undocumented changes that 
> are technically incompatible

I've seen this as a rationalization for intentional surprise breaking changes 
but I don't buy it.

Additionally your comments about (paraphrased) "the testsuite didn't 
demonstrate this usecase so I'm free to change it" are frankly a cop out -- 
your api returned a dict and a list, that's part of the public api -- changing 
that is a breaking change.

--

___
Python tracker 

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

[issue43413] tuple subclasses allow arbitrary kwargs

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue44243] tkinter button colors on Mac

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> third party
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

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

Re: Pandas: How does df.apply(lambda work to create a result

[Cameron Simpson]

Disclaimer: I haven't actually used pandas.

On 26May2021 14:45, Veek M  wrote:
>t = pd.DataFrame([[4,9],]*3, columns=['a', 'b'])
>   a  b
>0  4  9
>1  4  9
>2  4  9

I presume you've printed "t" here. So the above table is str(t). Or 
possibly repr(t) if you were at the interactive prompt. It is a human 
readable printout of "t".

>t.apply(lambda x: [x]) gives
>a[[1, 2, 2]]
>b[[1, 2, 2]]
>How?? When you 't' within console the entire data frame is dumped but how are
>the individual elements passed into .apply()?

The doco for .apply seems to be here:


https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.apply.html

When you go "t.apply()", the class implementing "t" has its .apply() 
method called - this is what does the work. So "t" is a DataFrame, so 
you're calling DataFrame.apply as documented at the above link.

>From the output, I expect that it takes each row in the DataFrame and 
passed it to the lambda function, and produces a single column value 
from the result, in the end creating a new single column DataFrame. The 
docs suggets you can do more than that, also.

>I can't do lambda x,y: [x,y]
>because only 1 arg is passed so how does [4] generate [[ ]]

Because your lambda:

lambda x: [x]

is passed the whole row, which is a list. You're returning a single 
element list containing that list.

If you know the rows have exactly 2 values you could do this:

lambda x: [x[0]*2, x[1]*3]

to get the first column multiplied by 2 and the second by 3.

You might do better to write your lambda like this:

lambda row: [row]

just so that it is clear that you're getting the whole row rather than 
some single element from the row.

>Also - this:
> t.apply(lambda x: [x], axis=1)
>0[[139835521287488, 139835521287488]]
>1[[139835521287488, 139835521287488]]
>2[[139835521287488, 139835521287488]]
>vey weird - what just happened??

See the docs above for the effect the axis parameter has on _how_ .apply 
does its work.

>In addition, how do I filter data eg:  t[x] = t[x].apply(lambda x: x*72.72) I'd
>like to remove numeric -1 contained in the column output of t[x]. 'filter' only
>works with labels of indices, i can't do t[ t[x] != -1 ] because that will then
>generate all the rows and I have no idea how that will be translate to
>within a .apply(lambda x... (hence my Q on what's going on internally)

It looks like the .fliter method accepts an items parameter indicating 
which axis labels to keep. Use axis=0 to filter on the rows instead of 
the columns. Maybe something shaped like this?

t.filter(axis=0, items=[
label for label in t.labels if t[label][0] != -1
]).apply(.)

That looks pretty cumbersome and also requires a way to get the labels 
of "t", which I just made up as "t.labels". And I'm just guessing that 
"t[label][0]" might get you the cell value you want to test against -1.

I expect there's a cleaner way to do this.

>(could someone also tell me briefly the best way to use NNTP and filter
>out the SPAM - 'pan' and 'tin' don't work anymore afaik
>[eternal-september]  and I'm using slrn currently - the SLang regex is
>weird within the kill file - couldn't get it to work - wound up killing
>everything when I did
>Subject: [A-Z][A-Z][A-Z]+
>)

I confess I subscribe to the python-list mailing list, not the 
newsgroup. It has much much less spam, and the two are gatewayed so you 
can particpate either way. For example, you've posted to the newsgroup 
and I'm seeing your post in the mailing list. Likewise my reply will be 
going to the mailing list and copied to the newsgroup.

Come on over to the mailing list. It is rumoured to be much quieter.

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

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

STINNER Victor  added the comment:

Other recent ssl issues:

* bpo-43921
* bpo-44229
* bpo-44237

--

___
Python tracker 

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

Re: Data structure for plotting monotonically expanding data set

[dn via Python-list]

On 27/05/2021 21.28, Loris Bennett wrote:
> Hi,
> 
> I currently a have around 3 years' worth of files like
> 
>   home.20210527
>   home.20210526
>   home.20210525
>   ...
> 
> so around 1000 files, each of which contains information about data
> usage in lines like
> 
>   namekb
>   alice   123
>   bob 4
>   ...
>   zebedee 999
> 
> (there are actually more columns).  I have about 400 users and the
> individual files are around 70 KB in size.
> 
> Once a month I want to plot the historical usage as a line graph for the
> whole period for which I have data for each user.
> 
> I already have some code to extract the current usage for a single from
> the most recent file:
> 
> for line in open(file, "r"):
> columns = line.split()
> if len(columns) < data_column:
> logging.debug("no. of cols.: %i less than data col", len(columns))
> continue
> regex = re.compile(user)
> if regex.match(columns[user_column]):
> usage = columns[data_column]
> logging.info(usage)
> return usage
> logging.error("unable to find %s in %s", user, file)
> return "none"
> 
> Obviously I will want to extract all the data for all users from a file
> once I have opened it.  After looping over all files I would naively end
> up with, say, a nested dict like
> 
> {"20210527": { "alice" : 123, , ..., "zebedee": 999},
>  "20210526": { "alice" : 123, "bob" : 3, ..., "zebedee": 9},
>  "20210525": { "alice" : 123, "bob" : 1, ..., "zebedee": 999},
>  "20210524": { "alice" : 123, ..., "zebedee": 9},
>  "20210523": { "alice" : 123, ..., "zebedee": 999},
>  ...}
> 
> where the user keys would vary over time as accounts, such as 'bob', are
> added and latter deleted.
> 
> Is creating a potentially rather large structure like this the best way
> to go (I obviously could limit the size by, say, only considering the
> last 5 years)?  Or is there some better approach for this kind of
> problem?  For plotting I would probably use matplotlib.


NB I am predisposed to use databases. People without such skills will
likely feel the time-and-effort investment to learn uneconomic for such
a simple, single, example!


Because the expressed concern seems to be the size of the data-set, (one
assumes) only certain users' data will be graphed (at one time). Another
concern may be that every time the routine executes, it repeats the bulk
of its regex-based processing.

I would establish a DB with (at least, as appropriate) two tables: one
the list of files from which the data has been extracted, and the second
containing the data currently formatted as a dict. NB The second may
benefit from stating in "normal form" or splitting into related tables,
and certainly indexing.

Thus the process requires two steps: firstly to capture the data (from
the files) into the DB, and secondly to graph the appropriate groups or
otherwise 'chosen' users.

SQL will simplify data retrieval, and feeding into matplotlib (or
whichever tool). It will also enable simple improvements both to select
sub-sets of users or to project over various periods of time.

YMMV!
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41217] Obsolete note for default asyncio event loop on Windows

[edna]

edna  added the comment:

You guys missed a copy of the same note at a different location here:
https://docs.python.org/3/library/asyncio-eventloop.html#running-subprocesses

It's still visible in all versions of the documentation for Python >=3.8 and 
should be fixed as well, as I (e.g.) got confused by it! :)

(also added the same comment in PR 21360 at GitHub already!)

--
nosy: +e-d-n-a

___
Python tracker 

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

Re: imaplib: is this really so unwieldy?

[boB Stepp]

On Thu, May 27, 2021 at 6:22 PM Cameron Simpson  wrote:
>
> On 27May2021 18:42, hw  wrote:

> >So it seems that IMAP support through python is virtually non-existent.
>
> This still sureprises me, but I've not tried to use IMAP seriously. I
> read email locally, and collect it with POP instead. With a tool I wrote
> myself in Python, as it happens.

I am out of my league here, but what I found in one of my books might
be helpful.  Al Sweigart wrote a useful book, "Automate the Boring
Stuff in Python".  In chapter 16 he considers email.  In the "IMAP"
section he states:


Just as SMTP is the protocol for sending email, the Internet Message
Access Protocol (IMAP) specifies how to communicate with an email
provider’s server to retrieve emails sent to your email address.
Python comes with an imaplib module, but in fact the third-party
imapclient module is easier to use. This chapter provides an
introduction to using IMAPClient; the full documentation is at
http://imapclient.readthedocs.org/.

The imapclient module downloads emails from an IMAP server in a rather
complicated format. Most likely, you’ll want to convert them from this
format into simple string values. The pyzmail module does the hard job
of parsing these email messages for you. You can find the complete
documentation for PyzMail at http://www.magiksys.net/pyzmail/.

Install imapclient and pyzmail from a Terminal window. Appendix A has
steps on how to install third-party modules.


In the next little section he shows how to retrieve and delete emails
with IMAP using the two third-party tools mentioned above.  And of
course there is more.  Apparently this book is now in its second
edition.  The first edition is available online for free.  The link to
chapter 16 which discusses email is:
https://automatetheboringstuff.com/chapter16/  Hopefully this will
prove helpful to the OP.

HTH!
boB Stepp
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[STINNER Victor]

STINNER Victor  added the comment:


New changeset da9e0cb4dedf818540ad1f06305bb1ca9e568f51 by Miss Islington (bot) 
in branch '3.10':
bpo-42972: Fully implement GC protocol for re types (GH-26368) (GH-26414)
https://github.com/python/cpython/commit/da9e0cb4dedf818540ad1f06305bb1ca9e568f51


--

___
Python tracker 

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

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

STINNER Victor  added the comment:

So far, I failed to reproduce the crash on my up-to-date local Windows 10 VM 
("Version 21H1 (OS Build 19043.985)"). I built Python in release mode 
("PCbuild\build.bat -e -p x64" command). I'm using Visual Studio 2019.

test.pythoninfo:

Py_DEBUG: No (sys.gettotalrefcount() missing)
os.cpu_count: 2
platform.architecture: 64bit WindowsPE
platform.platform: Windows-10-10.0.19043-SP0

ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1k  25 Mar 2021
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 11, 15)
ssl.OP_ALL: -0x7fac
ssl.OP_NO_TLSv1_1: 0x1000
ssl.SSLContext.maximum_version: MAXIMUM_SUPPORTED
ssl.SSLContext.minimum_version: TLSv1_2
ssl.SSLContext.options: 
OP_NO_COMPRESSION|OP_ENABLE_MIDDLEBOX_COMPAT|OP_CIPHER_SERVER_PREFERENCE|OP_NO_SSLv3|0x54
ssl.SSLContext.protocol: PROTOCOL_TLS_CLIENT
ssl.SSLContext.verify_mode: CERT_REQUIRED

sys.version: 3.10.0b1+ (heads/pr/26411:e269fa13a7, May 28 2021, 00:46:49) [MSC 
v.1928 64 bit (AMD64)]
sys.version_info: sys.version_info(major=3, minor=10, micro=0, 
releaselevel='beta', serial=1)
sys.windowsversion: sys.getwindowsversion(major=10, minor=0, build=19043, 
platform=2, service_pack='')

--

___
Python tracker 

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

[miss-islington]

miss-islington  added the comment:


New changeset 59f9594f9018450101079eb47e06e3c44cfeee36 by Miss Islington (bot) 
in branch '3.10':
[3.10] bpo-44246: Update What's New for importlib.metadata. (GH-26408) 
(GH-26415)
https://github.com/python/cpython/commit/59f9594f9018450101079eb47e06e3c44cfeee36


--

___
Python tracker 

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

[issue44243] tkinter button colors on Mac

[Mark Roseman]

Mark Roseman  added the comment:

Let it go. Changing the Python docs to a behaviour that isn't guaranteed by the 
underlying library is a virtual guarantee that a later version of Tk (or even 
the way the API it uses behaves on another version of macOS) will have some 
other (unrelated) modifications that change the current behaviour to something 
else.

--

___
Python tracker 

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

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

STINNER Victor  added the comment:

https://github.com/python/cpython/pull/26411/checks?check_run_id=2687367477

test.pythoninfo:

Py_DEBUG: No (sys.gettotalrefcount() missing)
os.cpu_count: 2
os.environ[VS140COMNTOOLS]: C:\Program Files (x86)\Microsoft Visual Studio 
14.0\Common7\Tools\

platform.architecture: 64bit WindowsPE
platform.platform: Windows-10-10.0.17763-SP0


ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1k  25 Mar 2021
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 11, 15)
ssl.OP_ALL: -0x7fac
ssl.OP_NO_TLSv1_1: 0x1000
ssl.SSLContext.maximum_version: MAXIMUM_SUPPORTED
ssl.SSLContext.minimum_version: TLSv1_2
ssl.SSLContext.options: 
OP_NO_COMPRESSION|OP_ENABLE_MIDDLEBOX_COMPAT|OP_CIPHER_SERVER_PREFERENCE|OP_NO_SSLv3|0x54
ssl.SSLContext.protocol: PROTOCOL_TLS_CLIENT
ssl.SSLContext.verify_mode: CERT_REQUIRED


sys.version: 3.10.0b1+ (remotes/pull/26411/merge:dddae6a, May 27 2021, 
17:25:25) [MSC v.1928 64 bit (AMD64)]
sys.version_info: sys.version_info(major=3, minor=10, micro=0, 
releaselevel='beta', serial=1)
sys.windowsversion: sys.getwindowsversion(major=10, minor=0, build=17763, 
platform=2, service_pack='')

--

___
Python tracker 

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

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

STINNER Victor  added the comment:

https://dev.azure.com/Python/cpython/_build/results?buildId=81570=logs=c83831cd-3752-5cc7-2f01-8276919eb334

test.pythoninfo

Py_DEBUG: No (sys.gettotalrefcount() missing)

platform.architecture: 64bit WindowsPE
platform.platform: Windows-10-10.0.17763-SP0

ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1k  25 Mar 2021
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 11, 15)
ssl.OP_ALL: -0x7fac
ssl.OP_NO_TLSv1_1: 0x1000
ssl.SSLContext.maximum_version: MAXIMUM_SUPPORTED
ssl.SSLContext.minimum_version: TLSv1_2
ssl.SSLContext.options: 
OP_NO_COMPRESSION|OP_ENABLE_MIDDLEBOX_COMPAT|OP_CIPHER_SERVER_PREFERENCE|OP_NO_SSLv3|0x54
ssl.SSLContext.protocol: PROTOCOL_TLS_CLIENT
ssl.SSLContext.verify_mode: CERT_REQUIRED

sys.version: 3.10.0b1+ 
(remotes/origin/de21daee57079ec694adc248a39e718ea0cf43f9:de21daee5, May 27 
2021, ) [MSC v.1928 64 bit (AMD64)]
sys.version_info: sys.version_info(major=3, minor=10, micro=0, 
releaselevel='beta', serial=1)
sys.windowsversion: sys.getwindowsversion(major=10, minor=0, build=17763, 
platform=2, service_pack='')

--

___
Python tracker 

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

[Jason R. Coombs]

Jason R. Coombs  added the comment:


New changeset 28f12c9f4f39d283d823d81e311d863526dfdb54 by Jason R. Coombs in 
branch 'main':
bpo-44246: Update What's New for importlib.metadata. (#26408)
https://github.com/python/cpython/commit/28f12c9f4f39d283d823d81e311d863526dfdb54


--

___
Python tracker 

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

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +25009
pull_request: https://github.com/python/cpython/pull/26415

___
Python tracker 

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

Re: imaplib: is this really so unwieldy?

[Cameron Simpson]

On 27May2021 18:42, hw  wrote:
>On 5/26/21 12:25 AM, Cameron Simpson wrote:
>>On 25May2021 19:21, hw  wrote:
>>>On 5/25/21 11:38 AM, Cameron Simpson wrote:
On 25May2021 10:23, hw  wrote:
>>You'd be surprised how useful it is to make almost any standalone
>>programme a module like this - in the medium term it almost always pays
>>off for me. Even just the discipline of shoving all the formerly-global
>>variables in the main function brings lower-bugs benefits.
>
>What do you do with it when importing it?  Do you somehow design your 
>programs as modules in some way that makes them usable as some kind of 
>library funktion?

Michael Torrie addressed this. In short, inspecting __name__ tells you 
if your module was run as a main programme or imported. That's what the 
test for '__main__' checks.

So modules like this tend to be:

module code

if __name__ == '__main__':
run as a command line main programme

And I personally spell that last line as:

sys.exit(main(sys.argv))

and define a main() function near the top of the module.

>>Chris has addressed this. msgnums is list of the data components of 
>>the
>>IMAP response.  By going str(msgnums) you're not getting "the message
>>numbers as text" you're getting what printing a list prints. Which is
>>roughly Python code: the brakcets and the repr() of each list member.
>
>Well, of course I exepect to get message numbers returned from such a 
>library function, not the raw imap response.  What is the library for 
>when I have to figure it all out by myself anyway.

The library, for this particular library:
- conceals the async side, giving you plain request=>response function 
  calls
- parses the response in its generic structural form and hands you the 
  components

It's a relatively thin shim for the IMAP protocol itself, not a fully 
fledged mailbox parser.

Since the search function can return many many weird and wonderful 
things depending what you ask it for, this particular library (a) does 
not parse the search field parameter ('(UID)') or the responses. It 
passes them through and 9b) correspondingly does not interpret the 
result beyond unpacking the IMAP response into the data packets 
provided.

What you really want is a "search_uids()" function, which calls 
.search() with '(UID)' _and_ parses the particular style of ressponse 
that '(UID)' produces from a server. imaplib doesn't have that, and that 
is a usability deficiency. It could do with a small suite of 
convenience/helper functions that call the core IMAP methods in 
particular commonly used ways.

>>Notice that the example code accessed msgnums[0] - that is the first
>>data component, a bytes. That you _can_ convert to a string (under
>>assumptions about the encoding).
>
>And of course, I don't want to randomly convert bytes into strings ...

Well, you don't need to. Splitting on "whitespace" is enough - you then 
have a list of individual UID bytes objects, which can probably be 
passed areound opaquely - you don't ordinarily need to _care_ that 
they're bytes transcriptions of the server numeric UID _values_ - you 
can at that point just treat them as tokens.

>>By getting the "str" form of a list, you're forced into the weird [3:-2]
>>hack to ttrim the ends. But it is just a hack for a transcription
>>mistake, not a sane parse.
>
>Right, thats why I don't like it and is part of what makes it so unwieldy.

Bear with me - I'm going to be quite elaborate here.

That _particular_ problem is because you transcribed a 
list-of-bytes-objects as a string (as Python would have printed such a 
thing with the print() function). It's just the wrong thing to do here, 
regardless of the language.

Consider (at the Python interactive ">>> " prompt):

>>> nums = [1, 2, 3]

A list of ints. print(nums) outputs:

>>> print(nums)
[1, 2, 3]

print() works by writing out str() of each of its arguments. So the 
above is a string written to the output. Looking at str():

>>> str(nums)
'[1, 2, 3]'

It's a string, with a leading '[' character, a decimal transcription of 
the numeric values with ', ' between those transcriptions, and a 
trailing ']' character.

The single quotes above are the interactive interpreter printing that 
Python str value using repr(), as you would type it to a Python 
programme.

To do what you did with the msgnums I'd go:

str(nums)[1:-1].split(', ')

which would get me a list of str values. But that cumbersomeness is 
because of the str(nums), which turned nums into a string transcription 
of the list of values. Let's do the equivalent with a made up IMAP 
search response:

msgnums = [b'123 456 789']

The above, I gather, is the source of your [3:-2] thing: trim the "b['" 
and "']" markers.

I'm using msgnums here because you named it that way, but the response 
from a search() is actually a list of data components. For 
search('(UID)') that list one has one element, the bytes data component 
with UIDs transcribed within 

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

STINNER Victor  added the comment:

Another error (not the crash):

test_pha_required_nocert (test.test_ssl.TestPostHandshakeAuth) ...  server:  
new connection from ('127.0.0.1', 51128)
 client cert is None
 client did not provide a cert
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
TLS: (, 'write', TLSVersion.TLS
v1_3, _TLSContentType.ALERT, _TLSAlertType.CERTIFICATE_REQUIRED, b'\x02t')
Test server failure:
Traceback (most recent call last):
   File "C:\vstinner\python\main\lib\test\test_ssl.py", line 2444, in run
msg = self.read()
   File "C:\vstinner\python\main\lib\test\test_ssl.py", line 2421, in read
return self.sslconn.read()
   File "C:\vstinner\python\main\lib\ssl.py", line 1131, in read
return self._sslobj.read(len)
 ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a 
certificate (_ssl.c:2523)
FAIL

==
FAIL: test_pha_required_nocert (test.test_ssl.TestPostHandshakeAuth)
--
Traceback (most recent call last):
  File "C:\vstinner\python\main\lib\test\test_ssl.py", line 4463, in 
test_pha_required_nocert
self.assertEqual(s.recv(1024), b'OK\n')
AssertionError: b'' != b'OK\n'

--

___
Python tracker 

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

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

STINNER Victor  added the comment:

This issue now prevents me to merge 
https://github.com/python/cpython/pull/26414 backport :-(

I'm debugging it on Windows.

I tried:

vstinner@DESKTOP-DK7VBIL C:\vstinner\python\main>python -u -X dev -m test -u 
all test_ssl -m test_pha_required_nocert -v -F -j2
(...)
0:00:35 load avg: 8.32 [ 77/1] test_ssl failed
test_ssl: testing with 'OpenSSL 1.1.1k  25 Mar 2021' (1, 1, 1, 11, 15)
  under Windows ('10', '10.0.19042', 'SP0', 'Multiprocessor Free')
  HAS_SNI = True
  OP_ALL = 0x-7fac
  OP_NO_TLSv1_1 = 0x1000
test_pha_required_nocert (test.test_ssl.TestPostHandshakeAuth) ...  server:  
new connection from ('127.0.0.1', 51115)
 client cert is None
 client did not provide a cert
 server: connection cipher is now ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
TLS: (, 'write', TLSVersion.TLS
v1_3, _TLSContentType.ALERT, _TLSAlertType.CERTIFICATE_REQUIRED, b'\x02t')
Test server failure:
Traceback (most recent call last):
   File "C:\vstinner\python\main\lib\test\test_ssl.py", line 2444, in run
msg = self.read()
   File "C:\vstinner\python\main\lib\test\test_ssl.py", line 2421, in read
return self.sslconn.read()
   File "C:\vstinner\python\main\lib\ssl.py", line 1131, in read
return self._sslobj.read(len)
 ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a 
certificate (_ssl.c:2523)
FAIL

==
FAIL: test_pha_required_nocert (test.test_ssl.TestPostHandshakeAuth)
--
Traceback (most recent call last):
  File "C:\vstinner\python\main\lib\test\test_ssl.py", line 4458, in 
test_pha_required_nocert
with self.assertRaisesRegex(
AssertionError: SSLError not raised


This is not the crash, but the fact that the test is not reliable doesn't help 
to debug :-(


Moreover, I had to patch unittest locally, since a frame globals was None!?

test test_ssl crashed -- Traceback (most recent call last):
  File "C:\vstinner\python\main\lib\test\libregrtest\runtest.py", line 282, in 
_runtest_inner
refleak = _runtest_inner2(ns, test_name)
  (...)
  File "C:\vstinner\python\main\lib\unittest\result.py", line 209, in 
_count_relevant_tb_levels
while tb and not self._is_relevant_tb_level(tb):
  File "C:\vstinner\python\main\lib\unittest\result.py", line 205, in 
_is_relevant_tb_level
return '__unittest' in tb.tb_frame.f_globals
TypeError: argument of type 'NoneType' is not iterable

--

___
Python tracker 

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

[issue11176] [doc] give more meaningful argument names in argparse documentation

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

Can you give the original authors some credit too on the PR, if you built on 
their work, please?

We usually do it by putting co-author:  in the PR comment.

--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue23937] IDLE: revise window size, placement startup options

[Terry J. Reedy]

Terry J. Reedy  added the comment:

When I changed the title, I intended to broaden the issue beyond 'start 
maximized'.  Even for that, there are two possibilities. 1. Configure option 
(default as now).  2. Save 'current' position, which helps non-maximizers also. 
 So I am inclined to the latter with some definition of current.

If we add multiple panes, maximized will make more sense.

There is a subtle issue easy to not notice.  Scrolling is slightly different 
when the window height an integral number of lines, as it now is on startup, or 
pixels, as after resizing with zoom or mouse grab.  I believe 'lines' is enough 
better that I have considered snapping to 'lines' after changes.  Not now 
though.

The Settings dialog height is currently determined by the General tab.  It is 
already too high for some notebooks: on my macbook, I can barely click OK (with 
'OK' not visible) *after* putting the app bar on the side rather than bottom.  
We need to squeeze existing items rather than add another.

--

___
Python tracker 

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

Re: Problem with pip installation

[Mats Wichmann]

On 5/27/21 1:08 PM, Dennis Lee Bieber wrote:

On Thu, 27 May 2021 09:22:09 +0300, ? ???
 declaimed the following:


Good morning. I have o Windows 10 system and i can install pip. I try to
follow the instruction that i find on internet but the did not work. Also
itry to write the command pip install pip but again did not work. Also the
command py. did not work.  Thank you!


"did not work" is meaningless... cut the exact text from your
console window (not an image grab) with the commands you are entering and
the messages that you get...

Is the location of pip on your Windows PATH environment variable?





python -m pip

Python knows how to find the pip that goes with it - these days it's not 
at all uncommon to have several Pythons on a system.  Windows pythons 
are always initialized with pip these days so this is reliable.


I'm sure you've read every bit of advice on the internet already, but 
make sure you've looked over this one:


https://docs.python.org/3/using/windows.html

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

[issue44255] strptime and week numbers without week days

[Jaap van der Velde]

New submission from Jaap van der Velde :

When running:
```
datetime.strptime('2013 23', '%Y %W')
```
The result is `datetime.datetime(2013, 1, 1, 0, 0)`. When running:
```
datetime.strptime('2013 23 1', '%Y %W %w')
```
The result is `datetime.datetime(2013, 6, 10, 0, 0)`.

It seems that `%W` is ignored, unless `%w` is also provided. But instead of 
throwing an error, a result is returned that is needlessly inaccurate. It could 
(and should?) return the first day of the week as a default, if an error is 
undesirable. Similar to:
```
datetime.strptime('2013 3', '%Y %m')
```

--
components: Library (Lib)
messages: 394611
nosy: Jaap van der Velde
priority: normal
severity: normal
status: open
title: strptime and week numbers without week days
type: enhancement
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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[miss-islington]

Change by miss-islington :


--
pull_requests: +25008
pull_request: https://github.com/python/cpython/pull/26414

___
Python tracker 

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

[issue31790] double free or corruption (while using smem)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

pydev core has not touched 2.7 in a year.  Anyone else maintaining 2.7 has had 
a chance to grab 2.7 issues.  So all 2.7 issues should be closed unless 
obviously relevant to current issues (and even then have 2.7 removed).  I agree 
that the later does not apply here.

--
resolution:  -> wont fix
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[STINNER Victor]

STINNER Victor  added the comment:


New changeset d1c732912e20e89815aca2d986442d349e82e31f by Miss Islington (bot) 
in branch '3.10':
bpo-42972: Fully support GC protocol for _operator heap types (GH-26371) 
(GH-26413)
https://github.com/python/cpython/commit/d1c732912e20e89815aca2d986442d349e82e31f


--

___
Python tracker 

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

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Ugh, should we make this a release blocker?

--

___
Python tracker 

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

[issue26503] argparse with required field , not having new line separator in -help dispaly

[Irit Katriel]

Irit Katriel  added the comment:

issue11874 has been fixed and its PR has a unit test that seems similar to the 
case reported here (test_help_with_metavar). If you are still seeing this issue 
on 3.9 or higher, please create a new issue and include a code snippet that 
reproduces the problem.

--
nosy: +iritkatriel
resolution:  -> out of date
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

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

STINNER Victor  added the comment:

> Is this happening on the current 3.10 or just with a specific PR?

The test_httplib crash occured on https://github.com/python/cpython/pull/26411 
PR which is unrelated to ssl.

--

___
Python tracker 

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

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Is this happening on the current 3.10 or just with a specific PR?

--
nosy: +pablogsal

___
Python tracker 

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

[issue31790] double free or corruption (while using smem)

[Irit Katriel]

Irit Katriel  added the comment:

Terry, this is a 2.7 memory management issue with not a log to go by. Would you 
agree that there is no chance we can do anything about this?

--
nosy: +iritkatriel
status: open -> pending

___
Python tracker 

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

[issue43916] Mark static types newly converted to heap types as immutable: add Py_TPFLAGS_DISALLOW_INSTANTIATION type flag

[STINNER Victor]

STINNER Victor  added the comment:


New changeset e90e0422182f4ca7faefd19c629f84aebb34e2ee by Erlend Egeberg 
Aasland in branch 'main':
bpo-43916: Use test.support.check_disallow_instantiation() in test_tcl 
(GH-26412)
https://github.com/python/cpython/commit/e90e0422182f4ca7faefd19c629f84aebb34e2ee


--

___
Python tracker 

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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[miss-islington]

Change by miss-islington :


--
pull_requests: +25007
pull_request: https://github.com/python/cpython/pull/26413

___
Python tracker 

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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[STINNER Victor]

STINNER Victor  added the comment:


New changeset f4b70c22c8e37dd7a06702e30b121a6651683421 by Erlend Egeberg 
Aasland in branch 'main':
bpo-42972: Fully support GC protocol for _operator heap types (GH-26371)
https://github.com/python/cpython/commit/f4b70c22c8e37dd7a06702e30b121a6651683421


--

___
Python tracker 

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

[issue21633] Argparse does not propagate HelpFormatter class to subparsers

[Irit Katriel]

Irit Katriel  added the comment:

What Paul explained is also covered in the documentation here: 
https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers

--
nosy: +iritkatriel
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

[issue44252] test_ssl and test_httplib.HTTPSTest crash randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

Change by STINNER Victor :


--
title: test_ssl: test_pha_required_nocert() crashs randomly with "Windows fatal 
exception: access violation" on Windows -> test_ssl and test_httplib.HTTPSTest 
crash randomly with "Windows fatal exception: access violation" on Windows

___
Python tracker 

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

[issue44252] test_ssl: test_pha_required_nocert() crashs randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

STINNER Victor  added the comment:

I forgot the link:
https://github.com/python/cpython/pull/26411/checks?check_run_id=2687367477

Oh right, Erlend already reported exactly the same crash :-)

--

___
Python tracker 

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

[issue44252] test_ssl: test_pha_required_nocert() crashs randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

STINNER Victor  added the comment:

Crash also seen on test_httplib:

(...)
test_attributes (test.test_httplib.HTTPSTest) ... ok
test_host_port (test.test_httplib.HTTPSTest) ... ok
Windows fatal exception: access violation

Current thread 0x11ec (most recent call first):
  File "D:\a\cpython\cpython\lib\socket.py", line 502 in close
  File "D:\a\cpython\cpython\lib\ssl.py", line 1072 in _create
  File "D:\a\cpython\cpython\lib\ssl.py", line 518 in wrap_socket
  File "D:\a\cpython\cpython\lib\test\ssl_servers.py", line 37 in get_request
  File "D:\a\cpython\cpython\lib\socketserver.py", line 311 in 
_handle_request_noblock
  File "D:\a\cpython\cpython\lib\socketserver.py", line 237 in serve_forever
  File "D:\a\cpython\cpython\lib\test\ssl_servers.py", line 142 in run
  File "D:\a\cpython\cpython\lib\threading.py", line 1006 in _bootstrap_inner
  File "D:\a\cpython\cpython\lib\threading.py", line 963 in _bootstrap

Thread 0x13ec (most recent call first):
  File "D:\a\cpython\cpython\lib\socket.py", line 496 in _real_close
  File "D:\a\cpython\cpython\lib\ssl.py", line 1330 in _real_close
  File "D:\a\cpython\cpython\lib\socket.py", line 502 in close
  File "D:\a\cpython\cpython\lib\ssl.py", line 1072 in _create
  File "D:\a\cpython\cpython\lib\ssl.py", line 518 in wrap_socket
  File "D:\a\cpython\cpython\lib\http\client.py", line 1448 in connect
  File "D:\a\cpython\cpython\lib\http\client.py", line 969 in send
  File "D:\a\cpython\cpython\lib\http\client.py", line 1031 in _send_output
  File "D:\a\cpython\cpython\lib\http\client.py", line 1271 in endheaders
  File "D:\a\cpython\cpython\lib\http\client.py", line 1322 in _send_request
  File "D:\a\cpython\cpython\lib\http\client.py", line 1276 in request
  File "D:\a\cpython\cpython\lib\test\test_httplib.py", line 1950 in 
test_local_bad_hostname
  File "D:\a\cpython\cpython\lib\unittest\case.py", line 549 in _callTestMethod
  File "D:\a\cpython\cpython\lib\unittest\case.py", line 592 in run
  File "D:\a\cpython\cpython\lib\unittest\case.py", line 652 in __call__
  File "D:\a\cpython\cpython\lib\unittest\suite.py", line 122 in run
  File "D:\a\cpython\cpython\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\cpython\cpython\lib\unittest\suite.py", line 122 in run
  File "D:\a\cpython\cpython\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\cpython\cpython\lib\unittest\suite.py", line 122 in run
  File "D:\a\cpython\cpython\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\cpython\cpython\lib\unittest\runner.py", line 176 in run
  File "D:\a\cpython\cpython\lib\test\support\__init__.py", line 959 in 
_run_suite
  File "D:\a\cpython\cpython\lib\test\support\__init__.py", line 1082 in 
run_unittest
  File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 210 in 
_test_module
  File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 246 in 
_runtest_inner2
  File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 282 in 
_runtest_inner
  File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 154 in 
_runtest
  File "D:\a\cpython\cpython\lib\test\libregrtest\runtest.py", line 194 in 
runtest
  File "D:\a\cpython\cpython\lib\test\libregrtest\main.py", line 321 in 
rerun_failed_tests
  File "D:\a\cpython\cpython\lib\test\libregrtest\main.py", line 698 in _main
  File "D:\a\cpython\cpython\lib\test\libregrtest\main.py", line 641 in main
  File "D:\a\cpython\cpython\lib\test\libregrtest\main.py", line 719 in main
  File "D:\a\cpython\cpython\lib\test\__main__.py", line 2 in 
  File "D:\a\cpython\cpython\lib\runpy.py", line 86 in _run_code
  File "D:\a\cpython\cpython\lib\runpy.py", line 196 in _run_module_as_main
test_local_bad_hostname (test.test_httplib.HTTPSTest) ... 
Error: Process completed with exit code 1.

test.pythoninfo:

ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1k  25 Mar 2021
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 11, 15)
ssl.OP_ALL: -0x7fac
ssl.OP_NO_TLSv1_1: 0x1000
ssl.SSLContext.maximum_version: MAXIMUM_SUPPORTED
ssl.SSLContext.minimum_version: TLSv1_2
ssl.SSLContext.options: 
OP_NO_COMPRESSION|OP_ENABLE_MIDDLEBOX_COMPAT|OP_CIPHER_SERVER_PREFERENCE|OP_NO_SSLv3|0x54
ssl.SSLContext.protocol: PROTOCOL_TLS_CLIENT
ssl.SSLContext.verify_mode: CERT_REQUIRED
ssl.default_https_context.maximum_version: MAXIMUM_SUPPORTED
ssl.default_https_context.minimum_version: TLSv1_2
ssl.default_https_context.options: 
OP_NO_COMPRESSION|OP_ENABLE_MIDDLEBOX_COMPAT|OP_CIPHER_SERVER_PREFERENCE|OP_NO_SSLv3|0x54
ssl.default_https_context.protocol: PROTOCOL_TLS_CLIENT
ssl.default_https_context.verify_mode: CERT_REQUIRED
ssl.stdlib_context.maximum_version: MAXIMUM_SUPPORTED
ssl.stdlib_context.minimum_version: TLSv1_2
ssl.stdlib_context.options: 
OP_NO_COMPRESSION|OP_ENABLE_MIDDLEBOX_COMPAT|OP_CIPHER_SERVER_PREFERENCE|OP_NO_SSLv3|0x54
ssl.stdlib_context.protocol: PROTOCOL_TLS_CLIENT
ssl.stdlib_context.verify_mode: CERT_NONE

--

___
Python tracker 

[issue44243] tkinter button colors on Mac

[Terry J. Reedy]

Terry J. Reedy  added the comment:

#44254 is a followup to change turtledemo unpressed button colors to something 
on white.

--

___
Python tracker 

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

[issue44254] Change turtledemo button colors

[Terry J. Reedy]

New submission from Terry J. Reedy :

[Following up on #44243.]
tk/tkinter-based turtledemo buttons are currently white on something.  On Mac, 
configured foreground button colors are honored (while the button is 
unpressed), while background colors are ignored.  Given that the unpressed 
default is black on white, the configured result of white on something is white 
on white.

I don't like the current colors anyway, so I think we should change to 
something on white.  I am thinking of green, red, and blue for Start, Stop, and 
Clear.

--
components: Library (Lib)
messages: 394597
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Change turtledemo button colors
type: behavior
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

[issue44243] tkinter button colors on Mac

[Terry J. Reedy]

Terry J. Reedy  added the comment:

"The configure and cget subcommands can still manipulate the values, but do not 
cause any variation to the look of the widget." is wrong.  Setting the 
foreground color *does* change the unpressed foreground color, so that 'white' 
becomes 'white on white'.  I consider not being more explicit about which 
options are or or not fixed, or at least not warning about foreground, to be a 
doc buglet.  What a trap for someone trying to make a cross-platform dark 
theme.  But their docs are theirs.

And our docs are ours.  We can't change external tk or ttk docs, but how about 
adding the following to the our ttk doc, just above 'Combobox'?

Button

On macOS, the pressed colors are fixed as white on blue.  The background is 
otherwise fixed as white.  So an attempt at white on dark results in white on 
white.

--
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue44253] tkinter searches for tk.tcl in wrong directory

[Adam Stewart]

Adam Stewart  added the comment:

Thanks, in that case it sounds like the problem is that Spack installs tcl and 
tk to separate directories, but since tk depends on tcl and not the other way 
around, tcl has no way of knowing where tk is installed. I'll see if I can 
convince the other Spack devs to combine tcl and tk into a single package.

--

___
Python tracker 

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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

I can't contribute to that discussion, as it is on the committers ml, but I'll 
keep an eye on it. I'll refrain from further development on this issue until 
there's a consensus amongst the core devs.

--

___
Python tracker 

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

[issue44242] enum.IntFlag regression: missing values cause TypeError

[Ethan Furman]

Ethan Furman  added the comment:

I'm very much of the practicality beats purity philosophy, so I want to support 
the OP's flag without making them jump through hoops.

On the flip side, I also appreciate that there are folks that want the extra 
security...

So here's my plan:  remove the creation time check (which will remove the error 
for the OP), and then add a decorator to the enum module that does that 
creation time check -- just like the `unique` decorator enforces no aliases.

Now I just need a good name for that decorator:

- complete ?
- exhaustive ?
- all_named ?
- check_for_unnamed ?

--
assignee:  -> ethan.furman

___
Python tracker 

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

[issue43964] ctypes CDLL search path issue on MacOS

[Victor Lazzarini]

Victor Lazzarini  added the comment:

I have looked at this closely and it appears Python 3.6.5 has a search path for 
libraries and frameworks that is missing in the newer versions (3.7 onwards). 
I can load libraries from /usr/local/lib and ~/lib without any difficulties in 
3.6.5, just by passing the file name. In later versions this does not work, you 
need to pass a full path. Furthermore if these libraries have dependencies 
which are set with an rpath, the loading fails because the dependencies are not 
found. None of this is a problem in 3.6.5. This needs to be resolved because 
packages that are based on ctypes may be broken in versions >= 3.7

This is the case of Csound and ctcsound, for instance.

--

___
Python tracker 

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

[issue43964] ctypes CDLL search path issue on MacOS

[Victor Lazzarini]

Change by Victor Lazzarini :


--
versions: +Python 3.7, Python 3.8

___
Python tracker 

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

[issue41611] IDLE: problems with completions on Mac

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The completion freeze fix is easily backported to non-Windows installations.

1. Run IDLE
2. File => Open Module, enter 'idlelib.autocomplete_w', OK.
3. Goto line 247 (3.9) or 250 (3.10) with "acw.update".
4. Add # in from of above to disable it.
5. Save and close IDLE, then restart.

For me, with 3.10.0b1, this restores full functions, with boxes appearing as 
appropriate.  With 3.9.5, no freeze by also no box.  2 or 3 tabs brings up 
first match.  'pr' = print, 'int.' = 
int.as_integer_ratio.  As far as I know, the file is the same in both versions. 
 Both versions are the same in Shell and Editor, so it is not the improved 3.10 
shell.

--

___
Python tracker 

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

[issue44253] tkinter searches for tk.tcl in wrong directory

[Ned Deily]

Ned Deily  added the comment:

The message is coming from Tcl/Tk; tkinter is just passing it along and is 
otherwise not involved AFAIK. You don't need to use framework builds for Tcl or 
Tk on macOS but you should follow the recommendation of how to do a Unix build 
of Tcl and Tk as far as configure options and placement of directories. When 
built properly Tcl should have no trouble finding Tk and the tk.tcl file.

--
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: crash -> 

___
Python tracker 

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

Re: learning python ...

[Peter J. Holzer]

On 2021-05-27 20:59:47 +0200, hw wrote:
> On 5/25/21 3:09 PM, Greg Ewing wrote:
> > On 25/05/21 5:56 pm, Avi Gross wrote:
> > > Var = read in something from a file and make some structure like a
> > > data.frame
> > > Var = remove some columns from the above thing pointed to by Var
> > > Var = make some new calculated columns ditto
> > > Var = remove some rows ...
> > > Var = set some kind of grouping on the above or sort it and so on.
> > 
> > As long as all the values are of the same type, this isn't too bad,
> > although it might interfere with your ability to give the intermediate
> > results names that help the reader understand what they refer to.
> > 
> > A variable that refers to things of different *types* at different
> > times is considerably more confusing, both for a human reader and
> > for any type checking software you might want to use.
> 
> How would this matter when the variables are typeless?

It doesn't matter for Python. It does matter for some people -
especially those that think that variables have (or should have) a type.

Of course "type checking software" follows that paradigm.


> Often times, it's not very practical to figure out the type of a value
> before assigning it to a variable ...

In statically typed languages (like C, Java, Go, ...) you have to do
that. In dynamically typed languages like Python you don't and in
general can't.


> > > How can you write a recursive function without this kind of variable
> > > shadowing? Each invocation of a function places the internal
> > > namespace in front of the parent so the meaning of a variable name
> > > used within is always backed by  all the iterations before it.
> > 
> > Um, no. What you're describing is called "dynamic scoping", and
> > Python doesn't have it. Python is *lexically* scoped, meaning that
> > only scopes that textually enclose the function in the source are
> > searched for names. Frames on the call stack don't come into it.
> > 
> > > So what if you suggest we allow re-use of names but WARN you. ...
> > > The first 50 places may be in other instances of the recursive
> > > function and you have already been warned this way 49 times
> > 
> > If this were to be done, the shadowing would be detected at compile
> > time, so you would only be warned once.
> 
> Works fine in perl (and you can have it without warnings if you want to,
> though that's not recommended):
> 
> 
> perl -e 'use warnings; my $shadow; my $shadow; my $shadow';
> "my" variable $shadow masks earlier declaration in same scope at -e line 1.
> "my" variable $shadow masks earlier declaration in same scope at -e line 1.

That's something different. Here you are redeclaring the same variable
in the same scope (Note that this cannot happen in Python because you
don't declare variables in Python). 

If you write something like this:


#!/usr/bin/perl
use v5.12;
use warnings;

my $x = 5;
{
my $x = 10; 
say $x;
}
say $x;


You won't get a warning, and the program will print 
--
10
5
--


But dynamic scope is something different. It's based on the call stack,
not syntax. In Perl, you get dynamically scoped variables with local.
This is quite deprecated and mostly used to temporarily shadow
predefined variables like $/ (although I've occasionally used it for
other purposes, too).

hp

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


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

Re: imaplib: is this really so unwieldy?

[hw]

On 5/25/21 3:55 PM, Grant Edwards wrote:

On 2021-05-25, hw  wrote:


I'm about to do stuff with emails on an IMAP server and wrote a program
using imaplib


My recollection of using imaplib a few years ago is that yes, it is
unweildy, oddly low-level, and rather un-Pythonic (excuse my
presumption in declaring what is and isn't "Pythonic").


It's good to know that it's not me and that I simply made a bad pick for 
something to learn python with :)



I switched to using imaplib2 and found it much easier to use. It's a
higher-level wrapper for imaplib.

I think this is the currently maintained fork:

   https://github.com/jazzband/imaplib2

I haven't activly used either for several years, so things may have
changed...

--
Grant



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

[issue23937] IDLE: revise window size, placement startup options

[Tal Einat]

Tal Einat  added the comment:

In terms of its interface, IDLE is more like a REPL + text editor than what is 
commonly thought of as programming IDEs (Visual Studio, PyCharm/IDEA, Matlab, 
JupyterLab etc.)  Terminals and text editors almost universally do not launch 
maximized by default.  Therefore I think starting IDLE maximized would be an 
unnecessary departure from the common, expected UX of similar desktop apps.

I suggest closing this as "won't fix".

--
nosy: +taleinat

___
Python tracker 

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

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Although it feels the topic has shifted from the original concern (an 
unintentional incompatibility) to the broader topic of the API change to 
entry_points generally, I'm happy to address your comments:

> - I don't think they were discussed thoroughly, and when opposition was 
> presented it was not listened to thoroughly: 
> https://github.com/python/importlib_metadata/pull/278

Anyone reading that thread will see that I was responsive to your concerns, 
adapted the solution based on your concerns, and spent extra energy documenting 
the motivations for the change and exploring solutions until I came up with 
something that I believed would address the concerns and has since largely 
borne out that goal in the release.

> - the change significantly complicates importlib.metadata with lots of sneaky 
> types (they all look like builtin types but do not act like them)

The solution that I ultimately settled on in python/importlib_metadata#278 does 
not use "sneaky" or "cutsey" types, but in fact reduces the number of magic 
types. EntryPoints is a tuple subclass, EntryPoint is a namedtuple subclass 
(with __iter__ magic deprecated), and SelectableGroups is a compatibility shim 
to be removed. Which types are sneaky and look like built-in types but do not 
act like them?

> - it simultaneously introduces new apis and old apis which will both be 
> around for extended periods of time but immediately moves to 
> DeprecationWarning

Given that backports are available, I saw no strong reason to delay the 
DeprecationWarning. I was open to the possibility that the transition could 
prove too taxing and the deprecation would have to be delayed. This early 
exposure means that most projects will already have addressed the deprecation 
concerns prior to the release of Python 3.10. In 
https://github.com/python/importlib_metadata/issues/298, the SQLAlchemy team 
helped me understand a nuanced use-case I hadn't considered, where libraries 
don't necessarily have the luxury of requiring newer backport releases, but in 
that case, I developed a solution that would provide future compatibility even 
with older stdlib and backport releases (through 
backports.entry_points_selectable). As far as I understand, there are no known 
use-cases that aren't satisfied by this design.

> - the new apis aren't remarkably better than the old apis -- the motivation 
> was written as "typing issues" but without citing actual issues. in fact, the 
> new items are significantly more complicated to type properly

The typing issues were discussed here 
(https://github.com/pypa/twine/pull/728#pullrequestreview-573342005) in the PR 
referenced by python/importlib_metadata#278. The magic casting of a two tuple 
to an item of a dict was found to be incompatible and unsupported by mypy 
(https://github.com/python/mypy/issues/9938). I further expanded on the 
motivations that led to this approach in 
https://github.com/python/importlib_metadata/issues/282 and 
https://github.com/python/importlib_metadata/issues/284.

So while Twine is able to declare types properly using this new design, it was 
infeasible to do so in the old design. After the compatibility layers are 
removed, `entry_points` will simply return an `EntryPoints` object, which 
presents an iterable of `EntryPoint` objects but with some facilities for 
selection. It's straightforward and clean. Please demonstrate the complication 
you see with the current approach.

The new APIs are not only easier to describe with types, but they are easier to 
describe in documentation.

> - the change breaks many significantly important projects, from perusing 
> related issues it's at the very least flake8, pandas, virtualenv, astropy, 
> pytest, hypothesis -- and hundreds more from a quick github code search

I'm not aware of a single breakage. The code is compatible for all known 
use-cases, but does present a DeprecationWarning in some usages. In the case of 
flake8, I've proposed a solution to avoid the DeprecationWarning and move to 
the preferred design, even without requiring an updated importlib_metadata 
backport.

I'm invested in providing as seamless a transition as possible to all projects, 
and I believe this change accomplishes that. Please let me know if there's a 
project or application where that's not the case.

> personally I think [all API changes] should be reverted 

Given the amount of adoption already, reverting these changes is likely to 
cause more disruption than moving forward with them.

If you would like to see the changes reverted or adapted further, please 
provide an example of a use-case that's broken by the current approach. So far, 
the only example presented above appears contrived and not an actual concern. 
It's common for Python minor releases to introduce undocumented changes that 
are technically incompatible but in ways that affect few or no users.

--

___
Python 

Re: learning python ...

[hw]

On 5/25/21 3:09 PM, Greg Ewing wrote:

On 25/05/21 5:56 pm, Avi Gross wrote:
Var = read in something from a file and make some structure like a 
data.frame

Var = remove some columns from the above thing pointed to by Var
Var = make some new calculated columns ditto
Var = remove some rows ...
Var = set some kind of grouping on the above or sort it and so on.


As long as all the values are of the same type, this isn't too bad,
although it might interfere with your ability to give the intermediate
results names that help the reader understand what they refer to.

A variable that refers to things of different *types* at different
times is considerably more confusing, both for a human reader and
for any type checking software you might want to use.


How would this matter when the variables are typeless?

Often times, it's not very practical to figure out the type of a value 
before assigning it to a variable ...


How can you write a recursive function without this kind of variable 
shadowing? Each invocation of a function places the internal namespace 
in front of the parent so the meaning of a variable name used within 
is always backed by  all the iterations before it.


Um, no. What you're describing is called "dynamic scoping", and
Python doesn't have it. Python is *lexically* scoped, meaning that
only scopes that textually enclose the function in the source are
searched for names. Frames on the call stack don't come into it.

So what if you suggest we allow re-use of names but WARN you. ... The 
first 50 places may be in other instances of the recursive function 
and you have already been warned this way 49 times


If this were to be done, the shadowing would be detected at compile
time, so you would only be warned once.


Works fine in perl (and you can have it without warnings if you want to, 
though that's not recommended):



perl -e 'use warnings; my $shadow; my $shadow; my $shadow';
"my" variable $shadow masks earlier declaration in same scope at -e line 1.
"my" variable $shadow masks earlier declaration in same scope at -e line 1.


"Mask" seems like a much better word for this than "shadow" ...
--
https://mail.python.org/mailman/listinfo/python-list

[issue41611] IDLE: problems with completions on Mac

[Tal Einat]

Tal Einat  added the comment:

See a second PR for the originally reported bug, GH-26404.

--

___
Python tracker 

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

Re: imaplib: is this really so unwieldy?

[Michael Torrie]

On 5/27/21 10:42 AM, hw wrote:
> What do you do with it when importing it?  Do you somehow design your 
> programs as modules in some way that makes them usable as some kind of 
> library funktion?

Yes, precisely.  Typically I break up my python projects into logical
modules, which are each kind of like a library in their own right.  The
if __name__=="__main__" idiom is really handy for this. It lets me build
testing into each module. If I run the module directly, it can execute
tests on the functions in that module. If it's imported, the code inside
the if __name__=="__main__" block is not executed.  Sometimes I'll have
a python file that can run standalone, using command-line arguments, or
be imported by something else and used that.  All depends on my needs at
the moment, but this mechanism is very powerful.

Note that any py file is loaded and executed when imported.  So any
module-level initialization code gets run whether a file is imported or
run directly (which is why the if __name__=="__main__" idiom works).
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue44243] tkinter button colors on Mac

[Tal Einat]

Tal Einat  added the comment:

It appears that this behavior is the intended behavior of Tk on macOS.  Given 
that tkinter is meant to be a relatively straightforward wrapping of Tcl/Tk, it 
seems to me that we too should consider this not to be a bug, and resolve this 
issue as "won't fix".

--

___
Python tracker 

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

[issue44243] tkinter button colors on Mac

[Tal Einat]

Tal Einat  added the comment:

The Tcl/Tk devs have closed the issue I opened on their issue tracker as "not a 
bug", with the following comment:

"Because Tk on the Mac uses API's to draw buttons, some configuration options 
are set by the OS and not by Tk. This is documented in the button man page: "On 
Aqua/Mac OS X, some configuration options are ignored for the purpose of 
drawing of the widget because they would otherwise conflict with platform 
guidelines. The configure and cget subcommands can still manipulate the values, 
but do not cause any variation to the look of the widget. The options affected 
notably include -background and -relief." Closing this ticket as not a bug."

--

___
Python tracker 

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

[issue44253] tkinter searches for tk.tcl in wrong directory

[Adam Stewart]

New submission from Adam Stewart :

I'm trying to install Python with tkinter support using the Spack package 
manager. Spack adds the following flags to configure during install:
```
'--with-tcltk-libs=-L/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib
 -ltcl8.6 
-L/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib
 -ltk8.6'
```
It also sets the following environment variables:
```
TCLLIBPATH='/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tcl8.6
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/tcl8.6
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib64/tcl8.6';
 export TCLLIBPATH
TCL_LIBRARY=/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib;
 export TCL_LIBRARY
```
The install seems to correctly pick up tk/tcl and builds correctly. However, 
when I try to use tkinter, I see the following run-time error:
```
$ python
Python 3.8.10 (default, May 27 2021, 13:28:01) 
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> tkinter._test()
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/python3.8/tkinter/__init__.py",
 line 4557, in _test
root = Tk()
  File 
"/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/python3.8/tkinter/__init__.py",
 line 2270, in __init__
self.tk = _tkinter.create(screenName, baseName, className, interactive, 
wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable tk.tcl in the following directories: 

/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tcl8.6/tk8.6
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tcl8.6/tk8.6/Resources/Scripts
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/tcl8.6/tk8.6
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib/tcl8.6/tk8.6/Resources/Scripts
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib64/tcl8.6/tk8.6
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tk-8.6.11-ydmhrbboheucxsuhrnyoxqaihgna5dfe/lib64/tcl8.6/tk8.6/Resources/Scripts
 /Users/Adam/spack/opt/spack/darwin-ca
 
talina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tk8.6
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/lib/tk8.6/Resources/Scripts
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/tk8.6
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/tcl-8.6.11-n7nea33urrk25rkoqpsc2tdcgai5u4z2/tk8.6/Resources/Scripts
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/tk8.6
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/tk8.6/Resources/Scripts
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/lib/tk8.6
 
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/apple-clang-12.0.0/lib/tk8.6 
/Users/Adam/spack/opt/spack/dar
 
win-catalina-x86_64/apple-clang-12.0.0/python-3.8.10-fkj5vkn3tpottyv6yqoj5ucz2emstpvo/library

This probably means that tk wasn't installed properly.
```
It seems that tkinter searches for tk.tcl in `/lib`, but tk.tcl is 
actually installed in `/lib/tk8.6`. I asked the tk developers, but it 
looks like `/lib/tk8.6` is indeed the correct installation location: 
https://core.tcl-lang.org/tk/tktview/447bd3e4abe17452d19a80e6840dcc8a2603fcbc

Is there a way to tell tkinter where to find tk.tcl? If not, can we modify the 
default search path to search in `/lib/tk8.6`?

Related to https://github.com/spack/spack/issues/23780

--
components: Tkinter
messages: 394584
nosy: ajstewart
priority: normal
severity: normal
status: open
title: tkinter searches for tk.tcl in wrong directory
type: crash
versions: Python 3.8

___
Python tracker 

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Please, check also the discusion happening here:

https://mail.python.org/archives/list/python-committ...@python.org/thread/FHFI7QKWNHAVWVFTCHJGTYD3ZFVEUXDD/

--

___
Python tracker 

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

[issue43916] Mark static types newly converted to heap types as immutable: add Py_TPFLAGS_DISALLOW_INSTANTIATION type flag

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Please, check also the discusion happening here:

https://mail.python.org/archives/list/python-committ...@python.org/thread/FHFI7QKWNHAVWVFTCHJGTYD3ZFVEUXDD/

--

___
Python tracker 

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

Re: learning python ...

[hw]

When the idea is to learn something, it's not exactly helpful to abandon 
that idea when encountering the first obstacle or when someone tells you 
you don't like it as much as they do ...


On 5/25/21 7:56 AM, Avi Gross via Python-list wrote:

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

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

Yes code like: num = int(num)

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

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

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

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

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

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

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

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

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

Result, err = functionA(args)

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

If (err 

[issue43916] Mark static types newly converted to heap types as immutable: add Py_TPFLAGS_DISALLOW_INSTANTIATION type flag

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
pull_requests: +25006
pull_request: https://github.com/python/cpython/pull/26412

___
Python tracker 

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

Re: imaplib: is this really so unwieldy?

[Chris Angelico]

On Fri, May 28, 2021 at 4:04 AM Peter J. Holzer  wrote:
>
> On 2021-05-26 08:34:28 +1000, Chris Angelico wrote:
> > Yes, any given string has a single width, which makes indexing fast.
> > The memory cost you're describing can happen, but apart from a BOM
> > widening an otherwise-ASCII string to 16-bit, there aren't many cases
> > where you'll get a single wide character in a narrow string.
>
> A single emoji in a long English text.
>
> > Usually, if there are any wide characters, there'll be a good number
> > of them
>
> Oh, right. People who use emoji usually use a lot of them .
>
>

Exactly :) I can easily imagine a short block of text with just one
(say, a single email), but if you have a gigabyte or even a couple
hundred meg of text, the chances of *a single* emoji become
vanishingly slim.

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

Re: imaplib: is this really so unwieldy?

[Peter J. Holzer]

On 2021-05-26 08:34:28 +1000, Chris Angelico wrote:
> Yes, any given string has a single width, which makes indexing fast.
> The memory cost you're describing can happen, but apart from a BOM
> widening an otherwise-ASCII string to 16-bit, there aren't many cases
> where you'll get a single wide character in a narrow string.

A single emoji in a long English text.

> Usually, if there are any wide characters, there'll be a good number
> of them

Oh, right. People who use emoji usually use a lot of them .

hp

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


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

[issue44252] test_ssl: test_pha_required_nocert() crashs randomly with "Windows fatal exception: access violation" on Windows

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

GH 26411, run id 2687367477 also failed with an access violation:
https://github.com/python/cpython/pull/26411/checks?check_run_id=2687367477

Not in test_pha_required_nocert, but test_local_bad_hostname.

May be related.

--

___
Python tracker 

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

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

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue12463] Calling SocketServer.shutdown() when server_forever() was not called will hang

[Irit Katriel]

Irit Katriel  added the comment:

This was added to the documentation under issue39797.

--
nosy: +iritkatriel
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue43988] Add test.support.check_disallow_instantiation()

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

> Lib/test/test_tcl.py might use it [...]

Absolutely.

> Serhiy suggested to write an unit test for curses.ncurses_version:
> https://bugs.python.org/issue43916#msg391936
>
> This work can be done in bpo-43916.

All right.

--

___
Python tracker 

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

[issue43667] Solaris: Fix broken Unicode encoding in non-UTF locales

[STINNER Victor]

STINNER Victor  added the comment:

I merged your PR and backported it to add a NEWS entry, thanks.

--

___
Python tracker 

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

[issue43667] Solaris: Fix broken Unicode encoding in non-UTF locales

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 427232f9d221d54870fa3e89bd1dac55cf42243f by Miss Islington (bot) 
in branch '3.9':
bpo-43667: Add news fragment for Solaris changes (GH-26405) (GH-26410)
https://github.com/python/cpython/commit/427232f9d221d54870fa3e89bd1dac55cf42243f


--

___
Python tracker 

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

[issue43667] Solaris: Fix broken Unicode encoding in non-UTF locales

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 0574b0686d76e6f9199f800b5f32bd56eaff3c77 by Miss Islington (bot) 
in branch '3.10':
bpo-43667: Add news fragment for Solaris changes (GH-26405) (GH-26409)
https://github.com/python/cpython/commit/0574b0686d76e6f9199f800b5f32bd56eaff3c77


--

___
Python tracker 

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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[STINNER Victor]

STINNER Victor  added the comment:


New changeset fba42d11880f444bb94d9891e3949f082a57b9a9 by Erlend Egeberg 
Aasland in branch 'main':
bpo-42972: Fully implement GC protocol for re types (GH-26368)
https://github.com/python/cpython/commit/fba42d11880f444bb94d9891e3949f082a57b9a9


--

___
Python tracker 

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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[miss-islington]

Change by miss-islington :


--
pull_requests: +25005
pull_request: https://github.com/python/cpython/pull/26411

___
Python tracker 

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

[issue42972] [C API] Heap types (PyType_FromSpec) must fully implement the GC protocol

[STINNER Victor]

STINNER Victor  added the comment:

> GH-26399 is failing with an access violation on Windows. It's failing in one 
> of the flaky tests. I wonder if the segfault is related to flaky tests 
> somehow...

I created bpo-44252 to track this crash, it might be unrelated to commit 
dcb8786a9848516e823e090bb36079678913d8d3. Even if it's related, I prefer to 
track it separated to ease collaboration and focus to this issue to the GC 
protocol.

--

___
Python tracker 

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

[issue44252] test_ssl: test_pha_required_nocert() crashs randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +erlendaasland
priority: normal -> 

___
Python tracker 

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

[issue44252] test_ssl: test_pha_required_nocert() crashs randomly with "Windows fatal exception: access violation" on Windows

[STINNER Victor]

New submission from STINNER Victor :

Christian Heimes reported a crash in bpo-42972:
https://bugs.python.org/issue42972#msg394520
---
GH-26399 is failing with an access violation on Windows. It's failing in one of 
the flaky tests. I wonder if the segfault is related to flaky tests somehow...

https://dev.azure.com/Python/cpython/_build/results?buildId=81570=logs=c83831cd-3752-5cc7-2f01-8276919eb334

test_pha_optional (test.test_ssl.TestPostHandshakeAuth) ... ok
test_pha_optional_nocert (test.test_ssl.TestPostHandshakeAuth) ... ok
test_pha_required (test.test_ssl.TestPostHandshakeAuth) ... ok
Windows fatal exception: access violation

Current thread 0x09e0 (most recent call first):
  File "D:\a\1\s\lib\linecache.py", line 63 in checkcache
  File "D:\a\1\s\lib\traceback.py", line 375 in extract
  File "D:\a\1\s\lib\traceback.py", line 494 in __init__
  File "D:\a\1\s\lib\traceback.py", line 132 in format_exception
  File "D:\a\1\s\lib\test\test_ssl.py", line 262 in handle_error
  File "D:\a\1\s\lib\test\test_ssl.py", line 2530 in run
  File "D:\a\1\s\lib\threading.py", line 1006 in _bootstrap_inner
  File "D:\a\1\s\lib\threading.py", line 963 in _bootstrap

Thread 0x03c4 (most recent call first):
  File "D:\a\1\s\lib\threading.py", line 1102 in _wait_for_tstate_lock
  File "D:\a\1\s\lib\threading.py", line 1086 in join
  File "D:\a\1\s\lib\test\test_ssl.py", line 2604 in run
  File "D:\a\1\s\lib\threading.py", line 1006 in _bootstrap_inner
  File "D:\a\1\s\lib\threading.py", line 963 in _bootstrap

Thread 0x1700 (most recent call first):
  File "D:\a\1\s\lib\ssl.py", line 1131 in read
  File "D:\a\1\s\lib\ssl.py", line 1256 in recv
  File "D:\a\1\s\lib\test\test_ssl.py", line 4471 in test_pha_required_nocert
  File "D:\a\1\s\lib\unittest\case.py", line 549 in _callTestMethod
  File "D:\a\1\s\lib\unittest\case.py", line 592 in run
  File "D:\a\1\s\lib\unittest\case.py", line 652 in __call__
  File "D:\a\1\s\lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\lib\unittest\suite.py", line 122 in run
  File "D:\a\1\s\lib\unittest\suite.py", line 84 in __call__
  File "D:\a\1\s\lib\unittest\runner.py", line 176 in run
  File "D:\a\1\s\lib\test\support\__init__.py", line 959 in _run_suite
  File "D:\a\1\s\lib\test\support\__init__.py", line 1082 in run_unittest
  File "D:\a\1\s\lib\test\test_ssl.py", line 5007 in test_main
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 246 in _runtest_inner2
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 282 in _runtest_inner
  File "D:\a\1\s\lib\test\libregrtest\runtest.py", line 154 in _runtest
  File "D:\a\1\s\lib\test\__main__.py", line 2 in 
  File "D:\a\1\s\lib\runpy.py", line 86 in _run_code
  File "D:\a\1\s\lib\runpy.py", line 196 in _run_module_as_main
##[error]Cmd.exe exited with code '-1073741819'.
---


Erlend E. Aasland added:
---
Hm, I'm unable to reproduce it w/addr sanitiser on macOS (FWIW).

$ ./python.exe -m test test_ssl -F -u all -m test_pha_required_nocert

Passing 1000 successful runs now. I'll see if I can get a Win dev env set up 
later.
---

I may be related to commit dcb8786a9848516e823e090bb36079678913d8d3 "bpo-42972: 
Fully implement GC protocol for ssl heap types (GH-26370)".

--
assignee: christian.heimes
components: SSL, Tests
messages: 394573
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_ssl: test_pha_required_nocert() crashs randomly with "Windows fatal 
exception: access violation" on Windows
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

[issue43667] Solaris: Fix broken Unicode encoding in non-UTF locales

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue43667] Solaris: Fix broken Unicode encoding in non-UTF locales

[miss-islington]

Change by miss-islington :


--
pull_requests: +25004
pull_request: https://github.com/python/cpython/pull/26410

___
Python tracker 

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

[issue43667] Solaris: Fix broken Unicode encoding in non-UTF locales

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 164a4f46d1606e21d82babc010e397a9116e6730 by Jakub Kulík in branch 
'main':
bpo-43667: Add news fragment for Solaris changes (GH-26405)
https://github.com/python/cpython/commit/164a4f46d1606e21d82babc010e397a9116e6730


--

___
Python tracker 

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

[issue43988] Add test.support.check_disallow_instantiation()

[STINNER Victor]

Change by STINNER Victor :


--
title: Add test.support.assert_dissallow_instantiation -> Add 
test.support.check_disallow_instantiation()
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

[issue43916] Mark static types newly converted to heap types as immutable: add Py_TPFLAGS_DISALLOW_INSTANTIATION type flag

[STINNER Victor]

STINNER Victor  added the comment:

Erlend added test.support.check_disallow_instantiation() function in bpo-43988 
to write tests for immutable types.

--

___
Python tracker 

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

[issue43988] Add test.support.assert_dissallow_instantiation

[STINNER Victor]

STINNER Victor  added the comment:

> I believe we can close this now, Victor. Please reopen if you disagree :)

I validated that all tests named "test(...)disallow(...)inst(...)" are now 
using support.check_disallow_instantiation().

Lib/test/test_tcl.py might use it in:

@support.cpython_only
def test_new_tcl_obj(self):
self.assertRaises(TypeError, _tkinter.Tcl_Obj)
self.assertRaises(TypeError, _tkinter.TkttType)
self.assertRaises(TypeError, _tkinter.TkappType)

Serhiy suggested to write an unit test for curses.ncurses_version:
https://bugs.python.org/issue43916#msg391936

This work can be done in bpo-43916.

--

___
Python tracker 

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

Re: Data structure for plotting monotonically expanding data set

[Peter J. Holzer]

On 2021-05-27 11:28:11 +0200, Loris Bennett wrote:
> I currently a have around 3 years' worth of files like
> 
>   home.20210527
>   home.20210526
>   home.20210525
>   ...
> 
> so around 1000 files, each of which contains information about data
> usage in lines like
> 
>   namekb
>   alice   123
>   bob 4
>   ...
>   zebedee 999
> 
> (there are actually more columns).  I have about 400 users and the
> individual files are around 70 KB in size.
> 
> Once a month I want to plot the historical usage as a line graph for the
> whole period for which I have data for each user.
[...]
> Obviously I will want to extract all the data for all users from a file
> once I have opened it.  After looping over all files I would naively end
> up with, say, a nested dict like
> 
> {"20210527": { "alice" : 123, , ..., "zebedee": 999},
>  "20210526": { "alice" : 123, "bob" : 3, ..., "zebedee": 9},
>  "20210525": { "alice" : 123, "bob" : 1, ..., "zebedee": 999},
>  "20210524": { "alice" : 123, ..., "zebedee": 9},
>  "20210523": { "alice" : 123, ..., "zebedee": 999},
>  ...}
> 
> where the user keys would vary over time as accounts, such as 'bob', are
> added and latter deleted.
> 
> Is creating a potentially rather large structure like this the best way
> to go (I obviously could limit the size by, say, only considering the
> last 5 years)?

I don't think that would be a problem. However, I assume that you want
to create one graph per user, not a single graph with 400 lines (that
would be very cluttered). So I would swap the levels around:

{
"alice": { "20210527": 123, "20210526": 123, ... },
"bob":   { "20210526": 3, "20210525", 1, ... },
"zebedee": { "20210527": 999, "20210526": 9, ... }
}

That way you have the data for each graph grouped together.

It might also be a good idea to use actual date objects instead of
strings.

hp

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


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

[issue44031] test_embed and test_tabnanny fails if the current directory is non-ASCII

[STINNER Victor]

STINNER Victor  added the comment:

Alexei S: "how we can fix this small problem in next releases of test_embed 
test_tabnanny? other tests didn't fail"

Any for any bug, someone has to investigate why "test_embed and test_tabnanny 
fails if the current directory is non-ASCII", and then someone has to propose a 
fix.

--

___
Python tracker 

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