date:20211226



Raymond Hettinger  added the comment:

> we should undo the deprecation of optparse in the documentation 
> (https://bugs.python.org/issue37103), since the stated justification 
> for that deprecation was that optparse will not be developed further.

While optparse that it isn't being developed further, therebut will not be 
taken away.  IIRC the reason for this was that it too had become difficult to 
build out and that is what necessitated the creation of argparse -- there 
wasn't clean way to add the desired features (subparsers, actions, etc).


> If it's going to be closed, it should at least be acknowledged 
> that it *is* a fundamental design flaw

That seems a spiteful demand. It is more correct to say that the design met its 
original intended goals but unfortunately the structure of the first pass scan 
precludes cleanly handling arguments with dashes.  The limitations are noted in 
the docs in the section, "Arguments containing -". 

As Eric pointed out, there are alternative argument parsing packages available 
on PyPI.

--

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

2021-12-26 Thread tongxiaoge


tongxiaoge  added the comment:

We make SSL3 disappear to newly built dependencies, the test_ssl success. Refer 
to the modification of OpenSSL on fedoras (address: 
https://src.fedoraproject.org/rpms/openssl/tree/f34 ）

```
 rm -f $RPM_BUILD_ROOT%{_sysconfdir}/pki/tls/*.dist
 
+# Next step of gradual disablement of SSL3.
+# Make SSL3 disappear to newly built dependencies.
+sed -i '/^\#ifndef OPENSSL_NO_SSL_TRACE/i\
+#ifndef OPENSSL_NO_SSL3\
+# define OPENSSL_NO_SSL3\
+#endif' $RPM_BUILD_ROOT/%{_prefix}/include/openssl/opensslconf.h
+
 %check
```

--
nosy: +sxt1001

___
Python tracker 

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

2021-12-26 Thread Anders Kaseorg


Anders Kaseorg  added the comment:

If argparse will not be developed further to fix this bug, then we should undo 
the deprecation of optparse in the documentation 
(https://bugs.python.org/issue37103), since the stated justification for that 
deprecation was that optparse will not be developed further.

The documentation should encourage programmers to use correct libraries, and 
optparse is correct here where argparse is not.  People who need the extra 
features of argparse and aren’t bothered by its incorrectness are welcome to 
decide to use it, but this is not the right default decision for the 
documentation to promote.

--

___
Python tracker 

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

[issue25044] bring BTPROTO_SCO inline with other Bluetooth protocols



Change by Daniel Diniz :


--
versions: +Python 3.11 -Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue7687] Bluetooth support untested



Change by Daniel Diniz :


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

[issue14844] netrc does not handle accentuated characters



Daniel Diniz  added the comment:

Now that a PR has landed in #28806 to improve shlex, we need to check whether 
this issue can/needs to move forward.

--
nosy: +ajaksu2, asvetlov
type:  -> behavior
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.2

___
Python tracker 

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

2021-12-26 Thread Tom Karzes



Tom Karzes  added the comment:

If it's going to be closed, it should at least be acknowledged that it *is* a 
fundamental design flaw, stemming from the misguided goal of trying (and 
necessarily failing) to allow options to be freely intermixed with positional 
arguments, which of course can't be done without dropping support for 
unrestricted string arguments.  This means that argparse does not, and 
apparently never will, support string argument values that begin with hyphens.  
Yes, I know that the equal sign can be used to handle *some* cases, but who 
wants to use equal signs to specify command-line options?  And there is no 
direct workaround for options that specify an nargs value of 2 or more.

Also, fixing this is *not* hard at all.  All that needs to be done is to add a 
keyword argument to the parser that tells it not to try to look ahead to find 
options, but to instead scan for them sequentially.  Just like any properly 
designed option parser does.  It's *easier* than trying to look ahead.

I have my own quick-and-dirty hack that approximates this, but it's ugly and 
disgusting, it only handles some cases, and I hate using it.  All the hack does 
is replace -- with a different prefix that I'm willing to avoid, then uses a 
different option prefix character so that the remaining strings starting with a 
single - are not seen as options.  This handles a single leading - in an option 
value.  It's not a general solution at all, but it's just barely good enough to 
solve my problem cases.

Yes, argparse has been successful, but the reason for that success is that it 
wasn't made for proficient users.  Rather, it was designed to cater to people 
who aren't very capable, and are perfectly happy to live with restricted string 
values if it means they can shuffle their command-line arguments willy nilly 
and still have it recognize them, rather than stopping when it should and 
giving the appropriate error.  It trades precision for ease of use.  This 
creates a vacuum for highly capable users who don't want to give up precise 
argument processing for the sake of a feature that's of no use to them in the 
first place.

Don't get me wrong.  There are a lot of nice features that argparse added which 
I find very useful.  The problem is it also sacrifices core functionality, 
making its predecessor, optparse, preferable for some applications.  In those 
cases, there is no transition path from optparse to argparse, since argparse 
does not handle all of the cases that optparse does.  And since argparse does 
not subsume the functionality of optparse, I find the decision to deprecate 
optparse highly questionable.

With optparse deprecated, Python no longer supports POSIX-compliant 
command-line option processing.  How is that a sound decision?

--

___
Python tracker 

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

[issue42079] Why does tarfile.next swallow InvalidHeaderError

2021-12-26 Thread Andrei Kulakov



Change by Andrei Kulakov :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> tarfile module next() method hides exceptions

___
Python tracker 

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

2021-12-26 Thread Clint Olsen



Clint Olsen  added the comment:

I think this should serve as a cautionary tale that while (POSIX) standards 
aren't always the best of solutions, they are often made for good reasons, and 
special care should be taken when you decide to deviate from them. Otherwise it 
just causes frustration.

While argparse behavior has some convenience, it isn't a very good fit for a 
multi-layered scripting environments where arguments for subordinate programs 
need consideration.

--

___
Python tracker 

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)



Raymond Hettinger  added the comment:

> I believe that the behavior is so deeply ingrained in how argparse
> works that it can't be changed.

I think so as well.  Handling arguments with a dash prefiew could be viewed as 
fundamental design flaw except for the fact that the module has been so 
successful (both before and after landing in the standard library).

I've come to believe that argparse is very difficult to change without risk of 
breaking many existing tools that depend on argparse working exactly the way it 
does now.

Also, this issue is over a decade old and no clear solution has emerged.


> at this point installing modules from PyPI is sufficiently easy
> that I'm not sure it makes sense to advocate for another command
> line parser in the stdlib.

I agree. It would be a hard sell at this point.

Let's close this one.  I don't think it is going to get solved.

--
resolution:  -> wont fix
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

[issue46184] Remove `netlify.toml`?



Change by Nikita Sobolev :


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

___
Python tracker 

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

[issue46184] Remove `netlify.toml`?



New submission from Nikita Sobolev :

It was added one year ago in https://bugs.python.org/issue37860

But, it is not used. Right now it does not do anything. Others report that it 
has a lot of limitations (including financial and technical ones): 
https://github.com/python/cpython/pull/15288#issuecomment-579476340

Original author even proposed another solution: 
https://bugs.python.org/issue37860 (PR is stale)

I propose to remove it. It can always be found in git.
Permalink to the last version in `main`: 
https://github.com/python/cpython/blob/2e3e0d23adca8d83722d939d6abd1e467d7578f7/netlify.toml

Related issue about `.travis.yml`: https://bugs.python.org/issue46178

--
components: Build
messages: 409220
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Remove `netlify.toml`?
type: behavior
versions: Python 3.11

___
Python tracker 

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

[issue46182] `super` and descriptor clarification



Raymond Hettinger  added the comment:

I'm reluctant to give any more space to the least important case, one that 
rarely arises in practice.  The text in the PR is wordy and IMO creates more 
confusion that it solves.

Per the dev-guide, we mostly avoid "preachy" text.  No, "it is recommended to 
avoid the single argument form".  In the unlikely event that a person needs 
this, we are not recommending against it.  It is in fact supported, tested, and 
mentioned in the documentation.  And to the extend we care to nudge users in 
one direction or another, the traditional way to deemphasize a feature is spend 
less time and space talking about it :-) 

At this point, I recommend just letting it be.  It feels like we're going down 
a rabbit hole here rather than solving problems that users actually have.  
These features are almost two decades old and the docs have been stable for a 
long time.  If there were a significant communication issue here, we would have 
known long ago.

To gain an appreciation for the challenges we face in documentation, take a 
look at the discussion in https://bugs.python.org/issue46173 .  

In the case of super(), more words don't make the docs better; it just adds 
more text that a user has to fight through to get the gestalt of what is going 
on.  When I talk to advanced users of the language, they almost never think of 
super() in more detail than is covered in the docs; instead, they've grokked 
the central concept of next-in-mro and that it is commonly used in two ways 
either to call parent class or to implement cooperative multiple inheritance.  
Ideally, we want to lead readers to that same understanding.  IMO, detailing 
the mechnanics of uncommon cases takes us in the opposite direction.

--

___
Python tracker 

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

[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs



Change by Arthur Milchior :


--
pull_requests: +28486
pull_request: https://github.com/python/cpython/pull/30271

___
Python tracker 

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

[issue46182] `super` and descriptor clarification

Arthur Milchior added the comment:

I do regret to have created a single bug, as I now realize that there are two
issues that are less related than I first imagined. Is there a way to split a
bug in two, so that both discussion can be discussed in different places.

Actually, after more search abound "unbound method", I discovered in
https://www.python.org/download/releases/3.0/whatsnew/ that this concept was
supposed to be gone for good in 3.0

The notion is also used in a few other places in the documentation but as far
as I can tell the only "definition" would be in
https://docs.python.org/3.11/c-api/method.html#method-objects.
While my first suggestion here was clearly wrong, I believe it still indicates
a documentation bug. In that if the concept is still in the language, "unbound"
should be a link to this concept. If the concept is not in the language
anymore, then it should not be used without explanation.
"super considered super" does not give a single example of super with a single
argument. Which is probably great, because this case is far less super.
However, this means that:
* there is currently no way for a user that want to discover python to know
that there is virtually no more reason to use super with a single argument.
* for someone reading a codebase with super called with a single argument, it
would be hard to figure out what it does.

Actually, I was going to create a PR
https://github.com/Arthur-Milchior/cpython/commit/dd453acad2b1f61867717cee4b47f944d37fb213
before seeing your answer, and while less certain, I still believe it has
merits

___
Python tracker

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

[issue46182] `super` and descriptor clarification



Raymond Hettinger  added the comment:

> "a base class ``B`` following ``A``" shouldn't it  be "the base 
> class"? . After all, there is at most one base class following ``A``

No. There can be other classes in the chain.  The first to match the lookup 
wins.

> Also, it may help clarify to write "is an object `obj`" and 
> "is a type `type2`" so that it get clear what `obj` and `type2` means.

Sorry, but I don't your proposed wording adds value.  While you may feel that 
it is more precise, it just adds redundant words without adding information.  
FWIW, we do this all over the docs, letting parameter names such as *obj* and 
*type2* communicate that we're referring to an object or a type.

> Hence, I believe that the parentheses should be removed after `m`

I took care of that in the other tracker issue.  That said, it arguably made 
the docs worse rather than better because by far the dominant use case for 
super() is calling methods rather than doing attribute lookup.  I only made the 
change to be consistent with the other attribute lookup examples.

> I find super documentation confusing because it uses multiple variables
> that are never introduced.

ISTM that you're looking for a full tutorial with fully worked worked out 
examples rather than English text interspersed with code snippets.  Consider 
reading the super-considered-super post for that purpose.

As for the existing text, I've wrestled with it for years and think we've hit a 
local optimum.  Expanding the text with more steps and descriptions of each 
step results in documentation that causes people's eyes to glaze over and to 
miss the main point of each sentence.

Also, remember that the documentation is factored.  The descriptor tutorial is 
primarily about descriptors.  A super() call is just one of four ways to invoke 
a descriptor.  From a descriptor howto point-of-view, all we want to 
communicate is that the attribute/method search starts at the next in the mro 
rather than the current instance.  It is not the goal of that section to fully 
document or discuss super().  

As for the main super() docs, that is the place talk about how super works; 
however, it is not the job of that section to explain the rest of Python (terms 
like bound, unbound, etc). In a way, the only job of this section is to 
differentiate how ``super(A, a).x`` differs from ``a.x``.  Other parts of the 
docs cover the general attribute lookup, C3 algorithm, method binding, etc.   
The use of super() is just a special case where where the search starts from 
the class right after the given or inferred *type* argument.

--
nosy: +rhettinger

___
Python tracker 

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

[issue46179] Delete selected item generate "<>" event or not in different version of tkinter or Python

2021-12-26 Thread Jason Yang



Jason Yang  added the comment:

>From https://core.tcl-lang.org/tk/reportlist, I found the same issue

ttk::treeview <> event bug 
https://core.tcl-lang.org/tk/tktview?name=2a6c62afd9

It is an old bug from 2014 anf not fixed, and now it fixed.
OK, no more question about it.

Thank you for your information.



B.R.,

Jason Yng

--
resolution:  -> fixed
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

[issue46170] Improving the error message when subclassing NewType



Nikita Sobolev  added the comment:

Turns out modern docs already have this problem fixed: 
https://docs.python.org/3/library/typing.html#newtype

--

___
Python tracker 

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

[issue46170] Improving the error message when subclassing NewType



Nikita Sobolev  added the comment:

> So maybe those docs are incorrect? I can't find anything in PEP 484 about 
> this.

Mypy even has an explicit test that NewType of NewType should work: 
https://github.com/python/mypy/blob/f96446ce2f99a86210b21d39c7aec4b13a8bfc66/test-data/unit/check-newtype.test#L162-L165

I tend to agree with this behavior. This allows us to create complex type-safe 
DSLs:

```python
from typing import NewType

UserId = NewType('UserId', int)
ProUserId = NewType('ProUserId', UserId)

x: ProUserId = ProUserId(UserId(1))
```

Mypy is happy with that!

I will open a new issue about incorrect docs.

--

___
Python tracker 

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

[issue46170] Improving the error message when subclassing NewType

2021-12-26 Thread Guido van Rossum



Guido van Rossum  added the comment:

Weird, the docs you cite claims


   # Also does not typecheck
   ProUserId = NewType('ProUserId', UserId)

but when I try it, it works at runtime and passes mypy (even with --strict) and 
also pyright.

So maybe those docs are incorrect? I can't find anything in PEP 484 about this.

In any case I'd drop the newline in the message -- other "Did you mean" errors 
don't have those.

--

___
Python tracker 

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

[issue44780] Incorrect message: "Invalid decimal literal" (python 3.10)

2021-12-26 Thread Andre Roberge



Andre Roberge  added the comment:

The last of these three cases (with FRACTION SLASH) is fixed 3.10.1.

The other two are still present in 3.10.1 and in 3.11.0a3

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

[issue46183] float function errors on negative number string with comma seperator ex: '-1, 234.0'

2021-12-26 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

Aside: for what it is worth, the British style with a middle dot is also not 
supported: float('1·234') also raises ValueError.

--

___
Python tracker 

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

[issue46183] float function errors on negative number string with comma seperator ex: '-1, 234.0'

2021-12-26 Thread Steven D'Aprano



Steven D'Aprano  added the comment:

The behaviour is correct and not a bug. Commas are not supported when 
converting strings to float.

The allowed format for floats as strings is described in the docs:

https://docs.python.org/3/library/functions.html#float

By the way, the negative sign is irrelevant. Commas are not supported 
regardless of whether there is a negative sign or not.

The difficulty with commas is that it is ambiguous whether float('1,234') 
should interpret the comma as British/American digit grouping separator, and 
return 1234.0, or as the European decimal point, and return 1.234. For good or 
bad, Python has a bias towards English (like most programming languages) and so 
it chooses to only recognise the decimal point as a dot in the British/American 
style, and reject the comma.

If you want to support European-style commas as the decimal point, the easiest 
way is to call float('1,234'.replace(',', '.'))

--
nosy: +steven.daprano
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

[issue46170] Improving the error message when subclassing NewType

2021-12-26 Thread Gobot1234



Gobot1234  added the comment:

> Do you have evidence that people make this particular mistake often? And that 
> the suggested solution is indeed what they should use? Why would you want to 
> subclass UserId?

I was just trying to implement something that I thought had a non-obvious error 
message and isn't necessarily initially obvious if you have the idea that 
NewType creates a new type/class. The documentation suggests this is what you 
should be doing instead of subclassing it
https://github.com/python/cpython/commit/342e800e974475cc302c46ed6d9f75276035278f#diff-8a0f115fde6769c122b771b6d0eca184c4580f7b5fabe2f0b0579c679424364fR101-R113

> Do we have examples of other error messages split across two lines like this?

No if you want me to remove it thats fine by me.

--

___
Python tracker 

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

[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs



Arthur Milchior  added the comment:

"a base class ``B`` following ``A``" shouldn't it be "the base class"? . After 
all, there is at most one base class following ``A``.

Also, I find it unclear what means "``x`` is returned unchanged, since in this 
context ``x`` is not a value which exists by itself.

--

___
Python tracker 

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

[issue46182] `super` and descriptor clarification



Arthur Milchior  added the comment:

"a base class ``B`` following ``A``" shouldn't it be "the base class"? . After 
all, there is at most one base class following ``A``.

Also, I find it unclear what means "``x`` is returned unchanged, since in this 
context ``x`` is not a value which exists by itself.

--

___
Python tracker 

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

[issue46179] Delete selected item generate "<>" event or not in different version of tkinter or Python

2021-12-26 Thread E. Paine



E. Paine  added the comment:

Reproduced on Wish 8.6.9 and 8.6.11 (same behaviour on 8.6.11 as reported on 
8.6.12).

I can't comment on why this is happening or which is correct behaviour so I 
would recommend taking it up with the Tk team 
https://core.tcl-lang.org/tk/reportlist (tkinter is just a thin wrapper of Tk 
and doesn't modify the event handling code). If you do take it up with them, 
here's the minimum equivalent Tcl code:

pack [ttk::treeview .t]
pack [button .b -text delete -command {.t delete 0}]
.t insert {} 0 -id 0 -text 0 -values {V1, V2}
bind .t <> {puts {select}}
.t selection set 0

--
nosy: +epaine, serhiy.storchaka

___
Python tracker 

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

[issue46182] `super` and descriptor clarification



Arthur Milchior  added the comment:

I just realized that https://bugs.python.org/issue20751 already tackled some of 
my issues. While I still believe that some things can be improved, this mean 
that some of the critiques in my first messages are not entirely up to date.

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

[issue20751] Harmonize descriptor protocol documentation: direct call, super binding with Descriptor Howto docs



Arthur Milchior  added the comment:

Shouldn't those change be ported to 3.10 and maybe even earlier version? They 
are great, but hard to find if you read the current version manual.

I'm just surprised by the term "dotted lookup". The remaining of the 
documentation mention "attribute access". So I assumed that there was a reason 
to use "dotted lookup" instead of "attribute access". If there is such a 
reason, it's not clear right now. Otherwise, if they are equivalent, I'd 
suggest remaining consistent in the term used.

I must note that "dotted lookup" is also used in the howto about descriptor, 
but it does not explain the difference with "attribute access".

One last note, I find it a little bit strange that `a` was supposed to be the 
value on which the access is done, and suddenly it becomes a part of the value.

--
nosy: +Arthur-Milchior

___
Python tracker 

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

[issue46170] Improving the error message when subclassing NewType

2021-12-26 Thread Guido van Rossum



Guido van Rossum  added the comment:

Do you have evidence that people make this particular mistake often? And that 
the suggested solution is indeed what they should use? Why would you want to 
subclass UserId?

Do we have examples of other error messages split across two lines like this?

--

___
Python tracker 

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

[issue46183] float function errors on negative number string with comma seperator ex: '-1, 234.0'

2021-12-26 Thread syed shah



New submission from syed shah :

>>> float ('-1,234')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: could not convert string to float: '-1,234'

--
components: Library (Lib)
messages: 409202
nosy: jj.github.jj
priority: normal
severity: normal
status: open
title: float function errors on negative number string with comma seperator ex: 
'-1,234.0'
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

[issue1438480] shutil.move raises OSError when copystat fails



Change by Daniel Diniz :


--
keywords:  -easy
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.3

___
Python tracker 

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

[issue46182] `super` and descriptor clarification