New submission from Samuel Marks :
astor fails with:
```
File "python3.8/site-packages/astor/code_gen.py", line 63, in to_source
generator.visit(node)
File "python3.8/site-packages/astor/node_util.py", line 143, in visit
return visitor(node)
File "pyth
Samuel Marks added the comment:
Just fixed the issue by using this value:
```py
"```(None)```" if sys.version_info[:2] >= (3, 9) else "```None```"
```
--
stage: -> resolved
status: open -> closed
___
Python trac
Samuel Marks added the comment:
Until this is accepted, I've modified my codebase:
```
from argparse import ArgumentParser
ArgumentParser(
prog=None if globals().get('__spec__') is None else 'python -m
{}'.format(__spec__.name.partition('.')[0])
)
Samuel Marks added the comment:
See https://bugs.python.org/msg353987 for manual test
--
Added file: https://bugs.python.org/file48643/prog-module-name-handler.patch
___
Python tracker
<https://bugs.python.org/issue22
New submission from Samuel Marks :
Since Python 2.3 alpha 2 [19-Feb-2003] `EX_OK` has existed… but only for Unix.
This adds support for Windows.
--
components: Windows
messages: 395203
nosy: paul.moore, samuelmarks, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
Change by Samuel Marks :
--
keywords: +patch
pull_requests: +25147
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26559
___
Python tracker
<https://bugs.python.org/issu
Samuel Marks added the comment:
`EXIT_SUCCESS` is defined in `stdlib.h`, as per
https://docs.microsoft.com/en-us/cpp/c-runtime-library/exit-success-exit-failure
(following the standard
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdlib.h.html)
There are also
https
New submission from Samuel Marks :
What works:
- python-3.7.9.exe python-3.8.9.exe
What fails:
- python-3.10.0b2.exe python-3.9.5.exe
(I'm debugging some regressions on my test suite… macOS and Linux [incl. in
Docker] work, Windows fails)
How to reproduce (macOS):
0. Install
New submission from Samuel Marks :
It's been too long since my family have been Polish!
(see screenshot of https://docs.python.org/3.11/library/parser.html )
My computer is only configured for English. Running Firefox 90.0b9 (64-bit) on
macOS 11.4 (20F71).
--
assignee: docs@p
Samuel Marks added the comment:
Yep exactly like my screenshot but now the Polish has turned Korean… my family
was never Korean!
--
___
Python tracker
<https://bugs.python.org/issue44
New submission from Samuel Marks :
I tried making `node.annotation` an `ast.Name("str", ast.Load())`, which worked
but when the AST was unparsed to a string it shows as `# type: `.
https://github.com/offscale/cdd-python/runs/3213864077
Replicate with:
```
unparse(Assign(annot
Samuel Marks added the comment:
Hmm, debugging my test and I was able to replicate it with this smaller one:
```
from ast import FunctionDef, arguments, Load, Name, AnnAssign, Store, BinOp,
Add, unparse
unparse(FunctionDef(args=arguments(args=[],
defaults
Samuel Marks added the comment:
Fixed with https://github.com/offscale/cdd-python/commit/079dc28
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
New submission from Samuel Marks :
This is an extremely minor improvement. Rather than create a `list`—using a
comprehension—then have it consumed by `.join`, one can skip the list
construction entirely.
(I remember this working from at least Python 2.7… probably earlier also
Samuel Marks added the comment:
@eric.smith No benchmarks offhand, but I'd expect it to be a very minor
improvement (if detectable).
If this gets accepted I'll probably do a bunch of little changes like this, to
improve things, e.g., replace '%' with '.format
Samuel Marks added the comment:
Yeah I hear ya, was just trying for the most concise issue title. I tend to
[over]use `map`, `filter`, `filterfalse` and other `itertools` and `operator`
methods in my own codebase.
Surprised with that result, that using an explicit list is actually faster
Samuel Marks added the comment:
Wait I don't understand why you wouldn't accept a wholesale replacement of all
`%` and `format` with f-strings through the entire CPython codebase [master
branch]?
BTW: Kinda unrelated, but would be great to have perspective on this little
proje
Samuel Marks added the comment:
I suppose that's a good justification to never improve/upgrade the syntax and
quality of the codebase.
In terms of automatic upgrades of the codebase, one could always replicate the
approach I use in doctrans—i.e., use of `ast` and/or `inspec
Samuel Marks added the comment:
EDIT: Just found https://github.com/ikamensh/flynt
--
___
Python tracker
<https://bugs.python.org/issue42699>
___
___
Python-bug
Samuel Marks added the comment:
There were only 12k occurrences, I'm sure I could manually go through that
in an afternoon. Would you accept it then?
On Tue, 22 Dec 2020, 12:22 am Eric V. Smith, wrote:
>
> Eric V. Smith added the comment:
>
> See https://github.com/ikame
New submission from Samuel Marks :
Had a couple of commits to try and fix it on GitHub Actions (as I was unable to
replicate locally), ended up with this very easy fix for Windows:
https://github.com/SamuelMarks/doctrans/commit/98203e9fee3e0a888ab1f4128011dde5fad98f63
To completely remove the
New submission from Samuel Marks :
I was on 3.10a4 on macOS 11.1 for ages, finally decided to upgrade to a5,
building from source. With latest `brew install openssl zlib`.
```
$ export LDFLAGS='-L/usr/local/opt/openssl@1.1/lib -L/usr/local/opt/zlib/lib'
$ export CPPFLAGS='-
Samuel Marks added the comment:
Nevermind it actually was that missing `PKG_CONFIG_PATH` line…
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Samuel Marks :
https://github.com/SamuelMarks/cpython/tree/3.9-compiler-fixes
--
components: Build
messages: 377205
nosy: samuelmarks
priority: normal
pull_requests: 21373
severity: normal
status: open
title: Fix some compiler warnings
type: compile error
versions
Samuel Marks added the comment:
Okay I'll redo it on master, here is my config, on macOS 10.15.6:
```
$ export PKG_CONFIG_PATH="/usr/local/opt/openssl@1.1/lib/pkgconfig"
$ export CPPFLAGS="-I/usr/local/opt/openssl@1.1/include"
$ export LDFLAGS="-L/usr/local
Change by Samuel Marks :
--
keywords: +patch
pull_requests: +21376
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22332
___
Python tracker
<https://bugs.python.org/issu
New submission from Samuel Marks :
Planned to fix all the compiler warnings on macOS. Ended up just fixing this
SQLite one:
```
Python-3.9.0/Modules/_sqlite/connection.c:1066:9: warning: 'sqlite3_trace' is
deprecated: first deprecated in macOS 10.12
[-Wdeprecated-de
Samuel Marks added the comment:
Yes, this commit extends his changes to include macOS support (for some reason
that SQLite version check doesn’t work properly on macOS; so this checks the
macOS version, knowing AOT when SQLite trace v1 APIs were deprecated.
Curious that
Samuel Marks added the comment:
@erlendaasland Hmm… just double-checked, and this issue is present on Python
3.8.6 and 3.9.0 but not master [d3b4e068077dd26927ae7485bd0303e09d962c02] as
you referenced.
Should I close this issue—and PR—then? - Backport from master to these
Samuel Marks added the comment:
👌
--
___
Python tracker
<https://bugs.python.org/issue42229>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Samuel Marks :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42229>
___
___
Python-bugs-list
New submission from Samuel Marks :
Backports https://github.com/python/cpython/pull/19581
https://bugs.python.org/issue40318 as per https://bugs.python.org/issue42229
--
components: Build
messages: 380185
nosy: samuelmarks
priority: normal
pull_requests: 22011
severity: normal
status
New submission from Samuel Marks :
Backports https://github.com/python/cpython/pull/19581
https://bugs.python.org/issue40318 as per https://bugs.python.org/issue42229
See also 3.9 backporting: https://bugs.python.org/issue42241
[not sure if this is how you do backporting, a new issue and GH
Samuel Marks added the comment:
Opened two issues and two PRs for 3.8 and 3.8:
- https://bugs.python.org/issue42241
- https://bugs.python.org/issue42242
--
___
Python tracker
<https://bugs.python.org/issue42
Change by Samuel Marks :
--
nosy: +samuelmarks
nosy_count: 4.0 -> 5.0
pull_requests: +22019
pull_request: https://github.com/python/cpython/pull/23102
___
Python tracker
<https://bugs.python.org/issu
Change by Samuel Marks :
--
pull_requests: +22020
pull_request: https://github.com/python/cpython/pull/23103
___
Python tracker
<https://bugs.python.org/issue40
Samuel Marks added the comment:
Done, thanks for the how-to:
- https://github.com/python/cpython/pull/23103 [3.8]
- https://github.com/python/cpython/pull/23102 [3.9]
--
___
Python tracker
<https://bugs.python.org/issue42
Samuel Marks added the comment:
Since we're bringing these back, would you accept a backport of these types?
[I'm writing a bunch of parsers/emitters—and starting to maintain an old
runtime type-checker—for 3.6+]
--
nosy: +samuelmarks
New submission from Samuel Marks:
Particularly for new programmers `True` makes more sense than `1` when doing
boolean logic.
If you aren't going to accept this patch; at least add in a sentence explaining
that: `> 1 == True`.
Best,
Samuel Marks
--
assignee: docs@python
co
39 matches
Mail list logo
