[Python-announce] logmerger 0.8.0 released

[Paul McGuire]

logmerger 0.8.0
===

New features:
- Added --inline command line option to view merged logs in a single inline 
column instead of side-by-side columns (side-by-side is the default)
- Added jump feature to move by number of lines or by a time period in 
microseconds, milliseconds, seconds, minutes, hours or days

Fixes:
- Fixed type annotations that broke running logmerger on Python 3.9.

Screenshot:
https://github.com/ptmcg/logmerger/blob/main/static/log1_log2_merged_tui_lr.jpg?raw=true


Use logmerger to view multiple log files, merged side-by-side with a common 
timeline using timestamps from the input files.
- merge ASCII log files
- detects various formats of timestamps
- detects multiline log messages
- merge .gz files without previously gunzip'ing
- merge .pcap files
- merge .csv files

Browse the merged logs using a textual-based TUI:
- vertical scrolling
- horizontal scrolling
- search/find next/find previous
- jump by number of lines or by time interval
- go to line
- go to timestamp

TUI runs in a plain terminal window, so can be run over a regular SSH session.


Installation


Install from PyPi;

pip install logmerger

For PCAP merging support:

pip install logmerger[pcap]


Github repo: https://github.com/ptmcg/logmerger
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 41.0.6 released

[Paul Kehrer]

PyCA cryptography 41.0.6 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.7+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v41-0-6):
* Fixed a null-pointer-dereference and segfault that could occur when
loading certificates from a PKCS#7 bundle.  Credit to pkuzco for
reporting the issue. CVE-2023-49083

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 41.0.5 released

[Paul Kehrer]

PyCA cryptography 41.0.5 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.7+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v41-0-5):
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4.
* Added a function to support an upcoming pyOpenSSL release.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] logmerger 0.7.0

[Paul McGuire]

logmerger 0.7.0
===

Screenshot:
https://github.com/ptmcg/logmerger/blob/main/static/log1_log2_merged_tui_lr.jpg?raw=true


Use logmerger to view multiple log files, merged side-by-side with a common 
timeline using timestamps from the input files.

- merge ASCII log files
  - detects various formats of timestamps
  - detects multiline log messages
- merge .gz files without previously gunzip'ing
- merge .pcap files
- merge .csv files

Browse the merged logs using a textual-based TUI:
- vertical scrolling
- horizontal scrolling 
- search/find next/find previous
- go to line
- go to timestamp

TUI runs in a plain terminal window, so can be run over a regular SSH session.


Installation


Install from PyPi;

pip install logmerger

For PCAP merging support:

pip install logmerger[pcap]


Github repo:  https://github.com/ptmcg/logmerger

___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 41.0.3 released

[Paul Kehrer]

PyCA cryptography 41.0.3 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.7+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v41-0-3):
* Fixed performance regression loading DH public keys.
* Fixed a memory leak when using ChaCha20Poly1305.
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.2.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] pyparsing 3.1.1 released

[Paul McGuire]

Thanks everyone for the great feedback on the 3.1.0 release! Caught some 
glaring regressions that slipped through my test suite. Just published version 
3.1.1: https://github.com/pyparsing/pyparsing/releases/tag/3.1.1

- Fixed regression in Word(min), reported by Ricardo Coccioli, good catch! 
(Issue #502)

- Fixed bug in bad exception messages raised by Forward expressions. PR 
submitted by Kyle Sunden, thanks for your patience and collaboration on this 
(#493).

- Fixed regression in SkipTo, where ignored expressions were not checked when 
looking for the target expression. Reported by catcombo, Issue #500.

- Fixed type annotation for enable_packrat, PR submitted by Mike Urbach, 
thanks! (Issue #498)

- Some general internal code cleanup. (Instigated by Michal Čihař, Issue #488)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 41.0.2 released

[Paul Kehrer]

PyCA cryptography 41.0.2 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.7+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v41-0-2):
* Fixed bugs in creating and parsing SSH certificates where critical
options with values were handled incorrectly. Certificates are now
created correctly and parsing accepts correct values as well as the
previously generated invalid forms with a warning. In the next
release, support for parsing these invalid forms will be removed.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] pyparsing 3.1.0 released

[Paul McGuire]

After several alpha and beta releases, I've finally pushed out version 3.1.0 of 
pyparsing. Here are the highlights:

NOTE: In the future release 3.2.0, use of many of the pre-PEP8 methods (such as 
`ParserElement.parseString`) will start to raise `DeprecationWarnings`. 3.2.0 
should get released some time later in 2023. I currently plan to completely 
drop the pre-PEP8 methods in pyparsing 4.0, though we won't see that release 
until at least late 2023 if not 2024. So there is plenty of time to convert 
existing parsers to the new function names before the old functions are 
completely removed. (Big help from Devin J. Pohly in structuring the code to 
enable this peaceful transition.)

Version 3.2.0 will also discontinue support for Python versions 3.6 and 3.7.


Version 3.1.0 - June, 2023
--

API CHANGES
---

- A slight change has been implemented when unquoting a quoted string parsed 
using the `QuotedString` class. Formerly, when unquoting and processing 
whitespace markers such as \t and \n, these substitutions would occur first, 
and then any additional '\' escaping would be done on the resulting string. 
This would parse "\\n" as "\". Now escapes and whitespace markers are 
all processed in a single pass working left to right, so the quoted string 
"\\n" would get unquoted to "\n" (a backslash followed by "n"). Fixes issue 
#474 raised by jakeanq, thanks!

- Reworked `delimited_list` function into the new `DelimitedList` class. 
`DelimitedList` has the same constructor interface as `delimited_list`, and in 
this release, `delimited_list` changes from a function to a synonym for 
`DelimitedList`. `delimited_list` and the older `delimitedList` method will be 
deprecated in a future release, in favor of `DelimitedList`.

- `ParserElement.validate()` is deprecated. It predates the support for 
left-recursive parsers, and was prone to false positives (warning that a 
grammar was invalid when it was in fact valid).  It will be removed in a future 
pyparsing release. In its place, developers should use debugging and analytical 
tools, such as `ParserElement.set_debug()` and 
`ParserElement.create_diagram()`. (Raised in Issue #444, thanks Andrea Micheli!)


NEW FEATURES AND ENHANCEMENTS
-

- `Optional(expr)` may now be written as `expr | ""`

  This will make this code:

  "{" + Optional(Literal("A") | Literal("a")) + "}"

  writable as:

  "{" + (Literal("A") | Literal("a") | "") + "}"

  Some related changes implemented as part of this work:
  - `Literal("")` now internally generates an `Empty()` (and no longer raises 
an exception)
  - `Empty` is now a subclass of `Literal`

  Suggested by Antony Lee (issue #412), PR (#413) by Devin J. Pohly.

- Added new class method `ParserElement.using_each`, to simplify code that 
creates a sequence of `Literals`, `Keywords`, or other `ParserElement` 
subclasses.

  For instance, to define suppressible punctuation, you would previously write:

  LPAR, RPAR, LBRACE, RBRACE, SEMI = map(Suppress, "(){};")

  You can now write:

  LPAR, RPAR, LBRACE, RBRACE, SEMI = Suppress.using_each("(){};")

  `using_each` will also accept optional keyword args, which it will pass 
through to the class initializer. Here is an expression for single-letter 
variable names that might be used in an algebraic expression:

  algebra_var = MatchFirst(
  Char.using_each(string.ascii_lowercase, as_keyword=True)
  )

- Added new builtin `python_quoted_string`, which will match any form of 
single-line or multiline quoted strings defined in Python. (Inspired by 
discussion with Andreas Schörgenhumer in Issue #421.)

- Extended `expr[]` notation for repetition of `expr` to accept a slice, where 
the slice's stop value indicates a `stop_on` expression:

  test = "BEGIN aaa bbb ccc END"
  BEGIN, END = Keyword.using_each("BEGIN END".split())
  body_word = Word(alphas)

  expr = BEGIN + Group(body_word[...:END]) + END
  # equivalent to
  # expr = BEGIN + Group(ZeroOrMore(body_word, stop_on=END)) + END

  print(expr.parse_string(test))

  Prints:

  ['BEGIN', ['aaa', 'bbb', 'ccc'], 'END']

- Added named field "url" to `pyparsing.common.url`, returning the entire 
parsed URL string.

- Added bool `embed` argument to `ParserElement.create_diagram()`. When passed 
as True, the resulting diagram will omit the ``, ``, and 
`` tags so that it can be embedded in other HTML source. (Useful when 
embedding a call to `create_diagram()` in a PyScript HTML page.)

- Added `recurse` argument to `ParserElement.set_debug` to set the debug flag 
on an expression and all of its sub-expressions. Requested by multimeric in 
Issue #399.

- Added '·' (Unicode MIDDLE DOT) to the set of Latin1.identbodychars.

- `ParseResults` now has a new method `deepcopy()`, in addition to the current 
`copy()` method. `copy()` only makes a shallow copy - any contained 
`ParseResults` are copied as references - 

[Python-announce] PyCA cryptography 41.0.1 released

[Paul Kehrer]

PyCA cryptography 41.0.1 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.7+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v41-0-1):
* Temporarily allow invalid ECDSA signature algorithm parameters in
X.509 certificates, which are generated by older versions of Java.
* Allow null bytes in pass phrases when serializing private keys.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 41.0.0 released

[Paul Kehrer]

PyCA cryptography 41.0.0 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.7+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v41-0-0):
* BACKWARDS INCOMPATIBLE: Support for OpenSSL less than 1.1.1d has
been removed. Users on older version of OpenSSL will need to upgrade.
* BACKWARDS INCOMPATIBLE: Support for Python 3.6 has been removed.
* BACKWARDS INCOMPATIBLE: Dropped support for LibreSSL < 3.6.
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.1.
* Updated the minimum supported Rust version (MSRV) to 1.56.0, from 1.48.0.
* Added support for the OCSPAcceptableResponses OCSP extension.
* Added support for the MSCertificateTemplate proprietary Microsoft
certificate extension.
* Implemented support for equality checks on all asymmetric public key types.
* Added support for aes256-...@openssh.com encrypted keys in
load_ssh_private_key().
* Added support for obtaining X.509 certificate signature algorithm
parameters (including PSS) via signature_algorithm_parameters().
* Support signing PSS X.509 certificates via the new keyword-only
argument rsa_padding on sign().
* Added support for ChaCha20Poly1305 on BoringSSL.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] Pyparsing 3.1.0b2 released (final beta!)

[Paul McGuire]

I just pushed release 3.1.0b2 of pyparsing. 3.1.0 with some fixes to bugs that 
came up in the past few weeks - testing works!

If your project uses pyparsing, please please *please* download this beta 
release (using "pip install -U pyparsing==3.1.0b2") and open any compatibility 
issues you might have at the pyparsing GitHub repo 
(https://github.com/pyparsing/pyparsing).

In the absence of any dealbreakers, I'll make the final release in June.

You can view the changes here: 
https://github.com/pyparsing/pyparsing/blob/master/CHANGES
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 40.0.2 released

[Paul Kehrer]

PyCA cryptography 40.0.2 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v40-0-2):
* Fixed compilation when using LibreSSL 3.7.2.
* Added some functions to support an upcoming pyOpenSSL release.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] Pyparsing 3.1.0b1 released

[Paul McGuire]

I just pushed release 3.1.0b1 of pyparsing. 3.1.0 will include support for 
python 3.12, and will be the last release to support 3.6 and 3.7.

If your project uses pyparsing, *please* download this beta release (using "pip 
install -U pyparsing==3.1.0b1") and open any compatibility issues you might 
have at the pyparsing GitHub repo (https://github.com/pyparsing/pyparsing).

You can view the changes here: 
https://github.com/pyparsing/pyparsing/blob/master/CHANGES
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 40.0.1 released

[Paul Kehrer]

PyCA cryptography 40.0.1 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v40-0-1):
* Fixed a bug where certain operations would fail if an object
happened to be in the top-half of the memory-space. This only impacted
32-bit systems.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 40.0.0 released

[Paul Kehrer]

PyCA cryptography 40.0.0 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v40-0-0):
* BACKWARDS INCOMPATIBLE: As announced in the 39.0.0 changelog, the
way cryptography links OpenSSL has changed. This only impacts users
who build cryptography from source (i.e., not from a wheel), and
specify their own version of OpenSSL. For those users, the CFLAGS,
LDFLAGS, INCLUDE, LIB, and CRYPTOGRAPHY_SUPPRESS_LINK_FLAGS
environment variables are no longer valid. Instead, users need to
configure their builds as documented here.
* Support for Python 3.6 is deprecated and will be removed in the next release.
* Deprecated the current minimum supported Rust version (MSRV) of
1.48.0. In the next release we will raise MSRV to 1.56.0. Users with
the latest pip will typically get a wheel and not need Rust installed,
but check Installation for documentation on installing a newer rustc
if required.
* Deprecated support for OpenSSL less than 1.1.1d. The next release of
cryptography will drop support for older versions.
* Deprecated support for DSA keys in load_ssh_public_key() and
load_ssh_private_key().
* Deprecated support for OpenSSH serialization in DSAPublicKey and
DSAPrivateKey.
* The minimum supported version of PyPy3 is now 7.3.10.
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.0.
* Added support for parsing SSH certificates in addition to public
keys with load_ssh_public_identity(). load_ssh_public_key() continues
to support only public keys.
* Added support for generating SSH certificates with SSHCertificateBuilder.
* Added verify_directly_issued_by() to Certificate.
* Added a check to NameConstraints to ensure that DNSName constraints
do not contain any * wildcards.
* Removed many unused CFFI OpenSSL bindings. This will not impact you
unless you are using cryptography to directly invoke OpenSSL’s C API.
Note that these have never been considered a stable, supported, public
API by cryptography, this note is included as a courtesy.
* The X.509 builder classes now raise UnsupportedAlgorithm instead of
ValueError if an unsupported hash algorithm is passed.
* Added public union type aliases for type hinting:
Asymmetric types: PublicKeyTypes, PrivateKeyTypes,
CertificatePublicKeyTypes, CertificateIssuerPublicKeyTypes,
CertificateIssuerPrivateKeyTypes
SSH keys: SSHPublicKeyTypes, SSHPrivateKeyTypes,
SSHCertPublicKeyTypes, SSHCertPrivateKeyTypes
PKCS12: PKCS12PrivateKeyTypes
PKCS7: PKCS7HashTypes, PKCS7PrivateKeyTypes
Two-factor: HOTPHashTypes
* Deprecated previously undocumented but not private type aliases in
the cryptography.hazmat.primitives.asymmetric.types module in favor of
new ones above.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 39.0.2 released

[Paul Kehrer]

PyCA cryptography 39.0.2 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v39-0-2)

* Fixed a bug where the content type header was not properly encoded
for PKCS7 signatures when using the ``Text`` option and ``SMIME``
encoding.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

Re: Line continuation and comments

[Paul Bryan]

Adding to this, there should be no reason now in recent versions of
Python to ever use line continuation. Black goes so far as to state
"backslashes are bad and should never be used":

https://black.readthedocs.io/en/stable/the_black_code_style/future_style.html#using-backslashes-for-with-statements

On Wed, 2023-02-22 at 01:24 -0800, Edmondo Giovannozzi wrote:
> Il giorno mercoledì 22 febbraio 2023 alle 09:50:14 UTC+1 Robert
> Latest ha scritto:
> > I found myself building a complicated logical condition with many
> > ands and ors 
> > which I made more manageable by putting the various terms on
> > individual lines 
> > and breaking them with the "\" line continuation character. In this
> > context it 
> > would have been nice to be able to add comments to lines terms
> > which of course 
> > isn't possible because the backslash must be the last character on
> > the line. 
> > 
> > Question: If the Python syntax were changed to allow comments after
> > line-ending 
> > backslashes, would it break any existing code? I can't think of an
> > example.
> 
> Well you can if you use parenthesis like in:
> x = 5
> a = (x > 3 and
> # x < 21 or
>  x > 100
>  )
> You don't need the "\" to continue a line in this case
> 

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

[Python-announce] PyCA cryptography 39.0.1 released

[Paul Kehrer]

PyCA cryptography 39.0.1 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v39-0-1)

* SECURITY ISSUE - Fixed a bug where Cipher.update_into accepted
Python buffer protocol objects, but allowed immutable buffers.
CVE-2023-23931
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.0.8.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

Re: Typing Number, PyCharm

[Paul Bryan]

On Mon, 2023-02-06 at 12:11 +, Weatherby,Gerard wrote:

> On the one hand, it is a well-known type, so it should be
> recognizable to users of an API. On the other hand, Number is
> entirely abstract, so it doesn’t provide useful type checking for the
> implementation; I had to add # noinspection PyTypeChecker to 2 *
> value to keep PyCharm from complaining. Additionally, it does not
> include the Decimal type.

Hmm...

Python 3.10.9 (main, Dec 19 2022, 17:35:49) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from numbers import Number
>>> from decimal import Decimal as D
>>> isinstance(D("1.0"), Number)
True

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

Re: Improvement to imports, what is a better way ?

[Paul Bryan]

On Thu, 2023-01-19 at 09:47 +1300, dn via Python-list wrote:

> The longer an identifier, the more it 'pushes' code over to the right
> or 
> to expand over multiple screen-lines. Some thoughts on this are
> behind 
> PEP-008 philosophies, eg line-limit.

I sympathize with this issue. I've pushed the line limit to 96, which
in my case removed this pain point. My argument—though subjective—is
that we have wide screens now, and it's quite unlikely production code
will be accessed through a vintage VT-100 terminal or printed on a 80-
column dot-matrix printer. That said, even if you stick to PEP-8
proper, `black` does most of the formatting work, and it seems to do a
reasonable job despite longer module identifiers.

> In the body of the code, if every time an external identifier is used
> it 
> must be prefixed by a full 'path', the cognitive "burden" shifts from
> the aspect highlighted (above), to a reading-burden. Thus, (in
> extreme 
> cases) moving towards a 'wall of text' problem.

I tend to agree this can be a problem in some cases, but I think those
can be made manageable. For brevity's sake, I import often-used data
types directly into the module's name space. It's far more rare that I
try to abbreviate a module name; common ones like importing pandas as
pd is a good counterexample.

> In using TDD, code is constructed module-by-module (not necessarily
> a 
> Python Module). So, when it comes time to call
> avMedia.fetch_the_file() 
> [sic] there is little thinking about the "avMedia" bit. The emphasis
> is 
> on the function-name, and it's parameters. 'I need that file so that
> I 
> can ...'.

I'm not entirely sure what you mean by not a Python module. Even in
test modules, I would only import what's required. If it turns out
`fetch_the_file` is called dozens of times or more, I would have no
qualm about importing it directly into the test module's namespace so
that it doesn't need to be prefixed at all.

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

Re: Improvement to imports, what is a better way ?

[Paul Bryan]

I would suggest allowing each module to define its own imports, don't
import what a module doesn't consume, keep them simple, avoid devising
a common namespace for each, and let tools like isort/black work out
how to order/express them in source files.

On Wed, 2023-01-18 at 10:43 -0800, Dan Kolis wrote:
> This program has lots of files and each is well segregated for a
> concept.
> 
> the top of each as a heap of imports, all identical. Well the very
> top has some one of's
> 
> import os as    os
> import sys as   sys
> import importlib as importlib
> import datetime as  dt
> from   tokenize import  maybe
> import signal
> 
> from   tkinter import filedialog as fd
> from   tkinter.messagebox import    showinfo
> import tkinter as   tk  
> from   tkinter import   ttk
> from   tkinter import   font
>  
> from   PIL import Image as  pl
> from   PIL import ImageTk   as  ii
> 
> # Imports part of this program 
> import aboutTime as tt  # Time dates timestamps and the
> like
> import avMedia as   av  # Audio and maybe video 'someday'
> well definitely lots of TTS text to speech
> import basicSwitchboard as  sc  # First switchboard lurking.
> Kickoff to sequence viewers
> import bestNotifications as bn  # Alerts, modals and
> notifications of many kinds including TK windows
> import bitBlitting as   bb  # Help - # A setup window with
> basic facts written into files and the workspace
> import configSetting as cs  # A setup window with basic facts
> written into files and the workspace
> import devPeeks as  dp  # Developments peek assets code
> for adding features and debugging
> import fileIo as    io  # File reads, writes even some of
> the the pickle and unpickling
> import forFun as    ff  # Staging area for uncertian
> features, also some dynamic code inclusion
> import fractionScreens as   fs  # Common window pieces for TK
> windows in sequence viewers
> import genomeDb as  gd  # IO to from databases external
> files gbk and others sure
> import globalIdeas as   gi  # Common code for stuff used
> everywhere and definition of share DOT OBJECTS
> import insertableEditors as ie  # Text editor(s) and support for
> that, some language issues managed too
> import modalSimple as   mo  # Modal windows icp seq ssues,
> not used much currently
> import osDependant as   od  # Operating system dependant
> calls and adaptions
> import pickle as    pk  # Packaging to and from file
> system for objects especially DOT OBJECTS
> import screenBuilder1 as    sb  # Screen maker for TKinter and
> TKinter ++ windows
> import selectViewer as  sv  # Window for picking which
> sequence viewers are enabled
> import sequencesMaintain as sm  # Touching up temporal version
> issues of DOT OBJECTS
> import sequencesOverview as so  # Working with sequences as macro
> facts, lists, see turn off etc
> import serverHttp1 as   sh1 # Servers for HTTP - User Support
> import serverHttp2 as   sh2 # Servers for HTTP - Protein
> viewing
> import specialFour as   sf  # Classes and stuff for viewer
> four, a very complex viewer
> import stagingNow as    sn  # More stabler new ideas getting
> tried out and moved in
> import taskingFunction as   tf  # Tasker for real timeish event
> processor calls. Has two versions both work
> import toastMaker as    tm  # Notifications
> import transFormations as   xf  # Sequence transFormations from
> mother natures ideas like DNA and RNA
> import unlovedMenus as  um  # Pretty rarely used ond
> fashioned menus. A while interface is in here that works
> import wayOffline as    wo  # Code not discarded but just
> studies, etc
> import windowsX as  wx  # Windows Life ! X11 esp TK not
> MS Windoze ...
> 
> So the file for instance fileIo.py has a duplicate of this.
> 
> I want to be able to call any code by using the two char prefix form
> anywhere. ex: io.get_Sequence(  'abc.fa' )
> 
> this seems weirdly disorderly. when it starts it sort of iterates
> down into objects, backs up etc.
> 
> What's the right way to do this ?
> 
> Thank you
> Dan

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

[Python-announce] PyCA cryptography 39.0.0 released

[Paul Kehrer]

PyCA cryptography 39.0.0 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v39-0-0):
* BACKWARDS INCOMPATIBLE: Support for OpenSSL 1.1.0 has been removed.
Users on older versions of OpenSSL will need to upgrade. Note that
this does not affect users of our wheels.
* BACKWARDS INCOMPATIBLE: Dropped support for LibreSSL < 3.5. The new
minimum LibreSSL version is 3.5.0. Going forward our policy is to
support versions of LibreSSL that are available in versions of OpenBSD
that are still receiving security support.
* BACKWARDS INCOMPATIBLE: Removed the encode_point and
from_encoded_point methods onEllipticCurvePublicNumbers, which had
been deprecated for several years. public_bytes()
andfrom_encoded_point() should be used instead.
* BACKWARDS INCOMPATIBLE: Support for using MD5 or SHA1 in
CertificateBuilder, other X.509 builders, and PKCS7 has been removed.
* BACKWARDS INCOMPATIBLE: Dropped support for macOS 10.10 and 10.11,
macOS users must upgrade to 10.12 or newer.
* ANNOUNCEMENT: The next version of cryptography (40.0) will change
the way we link OpenSSL. This will only impact users who build
cryptography from source (i.e., not from a wheel), and specify their
own version of OpenSSL. For those users, the CFLAGS, LDFLAGS, INCLUDE,
LIB, and CRYPTOGRAPHY_SUPPRESS_LINK_FLAGS environment variables will
no longer be respected. Instead, users will need to configure their
builds as documented here.
* Added support for disabling the legacy provider in OpenSSL 3.0.x.
* Added support for disabling RSA key validation checks when loading
RSA keys via load_pem_private_key(), load_der_private_key(), and
private_key(). This speeds up key loading but is unsafe if you are
loading potentially attacker supplied keys.
* Significantly improved performance for ChaCha20Poly1305 when
repeatedly calling encrypt or decrypt with the same key.
* Added support for creating OCSP requests with precomputed hashes
using add_certificate_by_hash().
* Added support for loading multiple PEM-encoded X.509 certificates
from a single input via load_pem_x509_certificates().

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

Re: set.add() doesn't replace equal element

[Paul Bryan]

It seems to me like you have to ideas of what "equal" means. You want 
to update a "non-equal/equal" value in the set (because of a different 
time stamp). If you truly considered them equal, the time stamp would 
be irrelevant and updating the value in the set would be unnecessary.


I would:

a) /not/ consider two different leases with two different time stamps 
to be equal, and
b) as already mentioned, store them in another data structure like a 
dictionary.


Not knowing the specifics of the DHCP object structure, if a DHCP lease 
object has some immutable key or other durable immutable attribute, I 
would be inclined to make that the dictionary key, and store the DHCP 
object as the value.



On Fri, Dec 30 2022 at 04:27:56 PM -0600, Ian Pilcher 
 wrote:

On 12/30/22 15:47, Paul Bryan wrote:
What kind of elements are being added to the set? Can you show 
reproducible sample code?


The objects in question are DHCP leases.  I consider them "equal" if
the lease address (or IPv6 prefix) is equal, even if the timestamps 
have

changed.  That code is not small, but it's easy to demonstrate the
behavior.

>>> import datetime
>>> class Foo(object):
... def __init__(self, index):
... self.index = index
... self.timestamp = datetime.datetime.now()
... def __eq__(self, other):
... return type(other) is Foo and other.index == self.index
... def __hash__(self):
... return hash(self.index)
... def __repr__(self):
... return f'Foo({self.index}) created at 
{str(self.timestamp)}'

...
>>> f1 = Foo(1)
>>> s = { f1 }
>>> s
{Foo(1) created at 2022-12-30 16:24:12.352908}
>>> f2 = Foo(1)
>>> f2
Foo(1) created at 2022-12-30 16:24:35.489208
>>> s.add(f2)
>>> s
{Foo(1) created at 2022-12-30 16:24:12.352908}

--

Google  Where SkyNet meets 
Idiocracy





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

Re: set.add() doesn't replace equal element

[Paul Bryan]

What kind of elements are being added to the set? Can you show 
reproducible sample code?


On Fri, Dec 30 2022 at 03:41:19 PM -0600, Ian Pilcher 
 wrote:
I just discovered this behavior, which is problematic for my 
particular

use.  Is there a different set API (or operator) that can be used to
add an element to a set, and replace any equal element?

If not, am I correct that I should call set.discard() before calling
set.add() to achieve the behavior that I want?

--

Google  Where SkyNet meets 
Idiocracy


--



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

String to Float, without introducing errors

[Paul St George]

So I am working on a physics paper with a colleague. We have a theory about 
Newtons Cradle. We answer the question why when you lift and drop balls 1 and 
2, balls 4 and 5 rise up. I could say more, but ... (if you are interested 
please write to me).

We want to illustrate the paper with animations. The theory includes distortion 
of the balls and this distortion is very very small. So, I am sent data with 
locations and dimensions to 13 decimal places. Something strange is happening 
with the animations: the balls are not moving smoothly. I do not know (yet) 
where the problem lies so it is difficult to provide a clear narrative.

Because there is a problem, I am investigating in all areas. This brings me to 
the question I asked here. I am not expecting six decimal places or three 
decimal places to be as accurate as thirteen decimal places, but I would like 
to be in control of or fully aware of what goes on under the bonnet.







 
>> On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:
On 12/17/2022 3:45 PM, Paul St George wrote:
> Thanks to all!
> It was the rounding rounding error that I needed to avoid (as Peter J. Holzer 
> suggested). The use of decimal solved it and just in time. I was about to 
> truncate the number, get each of the characters from the string mantissa, and 
> then do something like this:
> 
> 64550.727
> 
> 64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
> 
> Now I do not need to!

And that approach would not have helped you, because each of those 
calculations would be done as floating point, and you wouldn't have 
gotten any more precision (and maybe less) than simply doing 
float('64550.727').

Here is a small but interesting discussion thread about float vs Decimal:

https://stackoverflow.com/questions/32053647/comparing-python-decimals-created-from-float-and-string

Would you mind telling us why that degree of precision (that is, decimal 
vs float) matters for your problem?


>> On 17 Dec 2022, at 13:11, Alan Gauld > <https://mail.python.org/mailman/listinfo/python-list>> wrote:
>>
>> On 17/12/2022 11:51, Paul St George wrote:
>>> I have a large/long array of numbers in an external file. The numbers look 
>>> like this:
>>>
>>> -64550.727
>>> -64511.489
>>> -64393.637
>>> -64196.763
>>> -63920.2
>>
>>> When I bring the numbers into my code, they are Strings. To use the
>>> numbers in my code, I want to change the Strings to Float type
>>> because the code will not work with Strings but I do not want
>>> to change the numbers in any other way.
>>
>> That may be impossible. Float type is not exact and the conversion
>> will be the closest binary representation of your decimal number.
>> It will be very close but it may be slightly different when you
>> print it, for example. (You can usually deal with that by using
>> string formatting features.)
>>
>> Another option is to use the decimal numeric type. That has other
>> compromises associated with it but, if retaining absolute decimal
>> accuracy is your primary goal, it might suit you better.
>>
>>
>> -- 
>> Alan G
>> Author of the Learn to Program web site
>> http://www.alan-g.me.uk/
>> http://www.amazon.com/author/alan_gauld
>> Follow my photo-blog on Flickr at:
>> http://www.flickr.com/photos/alangauldphotos
>>
>>
> 









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

String to Float, without introducing errors

[Paul St George]

So I am working on a physics paper with a colleague. We have a theory about 
Newtons Cradle. We answer the question why when you lift and drop balls 1 and 
2, balls 4 and 5 rise up. I could say more, but ... (if you are interested 
please write to me).

We want to illustrate the paper with animations. The theory includes distortion 
of the balls and this distortion is very very small. So, I am sent data with 
locations and dimensions to 13 decimal places. Something strange is happening 
with the animations: the balls are not moving smoothly. I do not know (yet) 
where the problem lies so it is difficult to provide a clear narrative.

Because there is a problem, I am investigating in all areas. This brings me to 
the question I asked here. I am not expecting six decimal places or three 
decimal places to be as accurate as thirteen decimal places, but I would like 
to be in control of or fully aware of what goes on under the bonnet.

Here is a picture:
https://paulstgeorge.com/newton/cyclography.html
Thanks,
Paul



 
>> On 17 Dec 2022, at 16:54:05 EST 2022, Thomas Passin wrote:
On 12/17/2022 3:45 PM, Paul St George wrote:
> Thanks to all!
> It was the rounding rounding error that I needed to avoid (as Peter J. Holzer 
> suggested). The use of decimal solved it and just in time. I was about to 
> truncate the number, get each of the characters from the string mantissa, and 
> then do something like this:
> 
> 64550.727
> 
> 64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)
> 
> Now I do not need to!

And that approach would not have helped you, because each of those 
calculations would be done as floating point, and you wouldn't have 
gotten any more precision (and maybe less) than simply doing 
float('64550.727').

Here is a small but interesting discussion thread about float vs Decimal:

https://stackoverflow.com/questions/32053647/comparing-python-decimals-created-from-float-and-string

Would you mind telling us why that degree of precision (that is, decimal 
vs float) matters for your problem?


>> On 17 Dec 2022, at 13:11, Alan Gauld > <https://mail.python.org/mailman/listinfo/python-list>> wrote:
>>
>> On 17/12/2022 11:51, Paul St George wrote:
>>> I have a large/long array of numbers in an external file. The numbers look 
>>> like this:
>>>
>>> -64550.727
>>> -64511.489
>>> -64393.637
>>> -64196.763
>>> -63920.2
>>
>>> When I bring the numbers into my code, they are Strings. To use the
>>> numbers in my code, I want to change the Strings to Float type
>>> because the code will not work with Strings but I do not want
>>> to change the numbers in any other way.
>>
>> That may be impossible. Float type is not exact and the conversion
>> will be the closest binary representation of your decimal number.
>> It will be very close but it may be slightly different when you
>> print it, for example. (You can usually deal with that by using
>> string formatting features.)
>>
>> Another option is to use the decimal numeric type. That has other
>> compromises associated with it but, if retaining absolute decimal
>> accuracy is your primary goal, it might suit you better.
>>
>>
>> -- 
>> Alan G
>> Author of the Learn to Program web site
>> http://www.alan-g.me.uk/
>> http://www.amazon.com/author/alan_gauld
>> Follow my photo-blog on Flickr at:
>> http://www.flickr.com/photos/alangauldphotos
>>
>>
> 









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

Re: String to Float, without introducing errors

[Paul St George]

Thanks to all!
It was the rounding rounding error that I needed to avoid (as Peter J. Holzer 
suggested). The use of decimal solved it and just in time. I was about to 
truncate the number, get each of the characters from the string mantissa, and 
then do something like this:

64550.727

64550 + (7 * 0.1) + (2 * 0.01) + (7 * 0.001)

Now I do not need to!





> On 17 Dec 2022, at 13:11, Alan Gauld  wrote:
> 
> On 17/12/2022 11:51, Paul St George wrote:
>> I have a large/long array of numbers in an external file. The numbers look 
>> like this:
>> 
>> -64550.727
>> -64511.489
>> -64393.637
>> -64196.763
>> -63920.2
> 
>> When I bring the numbers into my code, they are Strings. To use the 
>> numbers in my code, I want to change the Strings to Float type 
>> because the code will not work with Strings but I do not want 
>> to change the numbers in any other way.
> 
> That may be impossible. Float type is not exact and the conversion
> will be the closest binary representation of your decimal number.
> It will be very close but it may be slightly different when you
> print it, for example. (You can usually deal with that by using
> string formatting features.)
> 
> Another option is to use the decimal numeric type. That has other
> compromises associated with it but, if retaining absolute decimal
> accuracy is your primary goal, it might suit you better.
> 
> 
> -- 
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
> 
> 

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

String to Float, without introducing errors

[Paul St George]

I have a large/long array of numbers in an external file. The numbers look like 
this:

-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
-63563.037
-63124.156
-62602.254
-61995.895
-61303.548
-60523.651
-59654.66
...

When I bring the numbers into my code, they are Strings. To use the numbers in 
my code, I want to change the Strings to Float type because the code will not 
work with Strings but I do not want to change the numbers in any other way.

So, I want my Strings (above) to be these numbers.

-64550.727
-64511.489
-64393.637
-64196.763
-63920.2
-63563.037
-63124.156
-62602.254
-61995.895
-61303.548
-60523.651
-59654.66
...

Please help!










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

[Python-announce] PyCA cryptography 38.0.4 released

[Paul Kehrer]

PyCA cryptography 38.0.4 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v38-0-4):
* Fixed compilation when using LibreSSL 3.6.0.
* Fixed error when using py2app to build an application with a
cryptography dependency.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

Re: Are these good ideas?

[Paul Bryan]

Seems like this is a use case for context managers and/or context
variables:

https://docs.python.org/3/library/contextlib.html
https://docs.python.org/3/library/contextvars.html


On Mon, 2022-11-14 at 17:14 +, Stephen Tucker wrote:
> Hi,
> 
> I have two related issues I'd like comments on.
> 
> Issue 1 - Global Values
> 
> Some years ago, I had a situation where
> (a) I could supply low-level functions that carry out tasks,
> (b) I needed those functions to communicate with each other, but
> (c) I had no access to the module that invoked my functions.
> 
> In order to achieve this, I hit on the idea that I also supply a
> module
> that I describe as a "global values" module. This module …
> (i) … defines the values that the functions use to communicate with
> each
> other;
> (ii) … is the subject of an import statement in each of my functions;
> (iii) … initialises its values at the start of each run (since the
> import
> only carries out an actual import once per session);
> (iv) … acts as a repository for the values thereafter.
> 
> This solution works well.
> 
> Given that I am not particularly concerned about efficiency,
> (1) Is this a reasonable way to achieve this goal?
> (2) Do you know of any better ways?
> 
> Issue 2 - Passed Parameters
> 
> I am now facing another situation where I am wanting to pass 6 or 7
> parameters down through several layers of logic (function A calling
> function B calling ... ) and for results to be passed back.
> 
> Having had the idea described above, I am considering using it again
> to
> save all the parameter-and-results passing.
> 
> I see nothing wrong with doing that, but I may well be missing
> something!
> 
> Comments, please!
> 
> Stephen Tucker.

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

[Python-announce] PyCA cryptography 38.0.3 released

[Paul Kehrer]

PyCA cryptography 38.0.3 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v38-0-3):
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL
3.0.7, which resolves CVE-2022-3602 and CVE-2022-3786.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 38.0.2 released

[Paul Kehrer]

PyCA cryptography 38.0.2 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v38-0-2):
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.0.6.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 38.0.1 released

[Paul Kehrer]

PyCA cryptography 38.0.1 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v38-0-1):
* Fixed parsing TLVs in ASN.1 with length greater than 65535 bytes (typically
seen in large CRLs).

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 38.0.0 released

[Paul Kehrer]

PyCA cryptography 38.0.0 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v38-0-0):
* Final deprecation of OpenSSL 1.1.0. The next release of cryptography
will drop support.
* We no longer ship manylinux2010 wheels. Users should upgrade to the
latest pip to ensure this doesn’t cause issues downloading wheels on
their platform. We now ship manylinux_2_28 wheels for users on new
enough platforms.
* Updated the minimum supported Rust version (MSRV) to 1.48.0, from
1.41.0. Users with the latest pip will typically get a wheel and not
need Rust installed, but check Installation for documentation on
installing a newer rustc if required.
decrypt() and related methods now accept both str and bytes tokens.
* Parsing CertificateSigningRequest restores the behavior of enforcing
that the Extension critical field must be correctly encoded DER. See
the issue for complete details.
* Added two new OpenSSL functions to the bindings to support an
upcoming pyOpenSSL release.
* When parsing CertificateRevocationList and CertificateSigningRequest
values, it is now enforced that the version value in the input must be
valid according to the rules of RFC 2986 and RFC 5280.
* Using MD5 or SHA1 in CertificateBuilder and other X.509 builders is
deprecated and support will be removed in the next version.
* Added additional APIs to SignedCertificateTimestamp, including
signature_hash_algorithm, signature_algorithm, signature, and
extension_bytes.
* Added tbs_precertificate_bytes, allowing users to access the
to-be-signed pre-certificate data needed for signed certificate
timestamp verification.
* KBKDFHMAC and KBKDFCMAC now support MiddleFixed counter location.
* Fixed RFC 4514 name parsing to reverse the order of the RDNs
according to the section 2.1 of the RFC, affecting method
from_rfc4514_string().
* It is now possible to customize some aspects of encryption when
serializing private keys, using encryption_builder().
* Removed several legacy symbols from our OpenSSL bindings. Users of
pyOpenSSL versions older than 22.0 will need to upgrade.
* Added AES128 and AES256 classes. These classes do not replace AES
(which allows all AES key lengths), but are intended for applications
where developers want to be explicit about key length.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

Re: python 3.10 vs breakage

[Paul Bryan]

The pronterface README doc [1] recommends Python 3.6, so I'd say that
it's likely incompatible with changes in Python 3.10. I think your best
option would be to either downgrade to their recommended version of
Python, or file an issue in their GitHub repository to address the
incompatibility. 

[1] https://github.com/kliment/Printrun/blob/master/README.md

On Fri, 2022-08-26 at 17:36 -0400, gene heskett wrote:
> On 8/26/22 16:54, Paul Bryan wrote:
> > Why can't you build linuxcnc with it? Why has Octoprint quit
> > talking to
> > 3d printers? Why won't pronterface buy it? Why can't you find a
> > 4.0.7
> > version of wxPython? Why is it sitting there staring at you? What
> > is
> > bookworm? What is bullseye?
> 
> Bullseye is the current debian-11, buster is last years, bookworm is
> next.
> 
> Linuxcnc builds just fine on armhf buster, with its python-3.9.4.
> fails 
> from 3.10 in bullseye. Pronterface.py can't find wxPython 4.0 or 
> greater, with 4.0.7 installed. Octoprint did work, but has now
> stopped. 
> So my 3d printing has become a sneakernet exercise again. Adding 3 to
> 5 
> more steps between OpenCSAD and the printer that will make my
> designs. 
> The error code file from this mornings attempt to run pronterface.py
> is at
> 
> <http://geneslinuxbox.net:6309/armhf>
> 
> Is there a workaround?
> 
> Thank you.
> > On Fri, 2022-08-26 at 16:37 -0400, gene heskett wrote:
> > > Greetings all;
> > > 
> > > Its now become obvious that 3.10 has broken some things. I can't
> > > build
> > > linuxcnc with it. And
> > > Octoprint has quit talking to 3d printers, now pronterface won't
> > > buy
> > > it,
> > > can't find a 4.0.7
> > > version of wxPython with it sitting there staring at us.
> > > 
> > > Whats chances of a fixed version for bookworm? Or even a bugs
> > > fixed
> > > release for bullseye?
> > > 
> > > Thanks all.
> > > 
> > > Cheers, Gene Heskett.
> > > -- 
> > > "There are four boxes to be used in defense of liberty:
> > >    soap, ballot, jury, and ammo. Please use in that order."
> > > -Ed Howdershelt (Author, 1940)
> > > If we desire respect for the law, we must first make the law
> > > respectable.
> > >    - Louis D. Brandeis
> > > Genes Web page <http://geneslinuxbox.net:6309/>
> > > 
> > 
> 
> 
> Cheers, Gene Heskett.

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

Re: python 3.10 vs breakage

[Paul Bryan]

Why can't you build linuxcnc with it? Why has Octoprint quit talking to
3d printers? Why won't pronterface buy it? Why can't you find a 4.0.7
version of wxPython? Why is it sitting there staring at you? What is
bookworm? What is bullseye?

On Fri, 2022-08-26 at 16:37 -0400, gene heskett wrote:
> Greetings all;
> 
> Its now become obvious that 3.10 has broken some things. I can't
> build 
> linuxcnc with it. And
> Octoprint has quit talking to 3d printers, now pronterface won't buy
> it, 
> can't find a 4.0.7
> version of wxPython with it sitting there staring at us.
> 
> Whats chances of a fixed version for bookworm? Or even a bugs fixed 
> release for bullseye?
> 
> Thanks all.
> 
> Cheers, Gene Heskett.
> -- 
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law
> respectable.
>   - Louis D. Brandeis
> Genes Web page 
> 

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

Re: subprocess.popen how wait complete open process

[Paul Bryan]

Sometimes, launching subprocesses can seem like punishment. I don't
think there is a standard cross-platform way to know when a launched
asynchronous process is "fully open" (i.e. fully initialized, accepting
user input).

On Sun, 2022-08-21 at 02:11 -0700, simone zambonardi wrote:
> Hi, I am running a program with the punishment subrocess.Popen(...)
> what I should do is to stop the script until the launched program is
> fully open. How can I do this? I used a time.sleep() function but I
> think there are other ways. Thanks

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

Re: Information about Dying kernel

[Paul Bryan]

Have you tried turning it off and back on again?

On Sun, 2022-08-07 at 18:59 +0200, nhlanhlah198506 wrote:
> Greetings What can I do if my computer said my kernels has died Thank
> you Sent from my Galaxy

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

Re: Which linux distro is more conducive for learning the Python programming language?

[Paul Bryan]

I wouldn't say any particular Linux distribution is appreciably better
for Python development than another. I would suggest using a version of
a Linux distribution that supports a recent Python release (e.g. 3.9 or
3.10).

On Thu, 2022-08-04 at 10:22 +0800, Turritopsis Dohrnii Teo En Ming
wrote:
> Subject: Which linux distro is more conducive for learning the Python
> programming language?
> 
> Good day from Singapore,
> 
> May I know which linux distro is more conducive for learning the
> Python programming language?
> 
> Since I have absolutely and totally FREE RHEL developer subscription
> (I don't need to spend a single cent), can I use Red Hat Enterprise
> Linux version 9.0 to learn Python?
> 
> Is it the most popular linux distro for learning Python?
> 
> I just want to know which linux distro and version is more conducive
> for learning Python. Because there are thousands of linux distros out
> there. And I just want to settle down on a particular linux distro
> and
> version.
> 
> Thank you.
> 
> Regards,
> 
> Mr. Turritopsis Dohrnii Teo En Ming
> Targeted Individual in Singapore
> 4 Aug 2022 Thursday
> Blogs:
> https://tdtemcerts.blogspot.com
> https://tdtemcerts.wordpress.com

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

Re: Subtract n months from datetime

[Paul Bryan]

Here's how my code does it:


import calendar

def add_months(value: date, n: int):
  """Return a date value with n months added (or subtracted if
negative)."""
  year = value.year + (value.month - 1 + n) // 12
  month = (value.month - 1 + n) % 12 + 1
  day = min(value.day, calendar.monthrange(year, month)[1])
  return date(year, month, day)

Paul

On Tue, 2022-06-21 at 05:29 +0100, Paulo da Silva wrote:
> Hi!
> 
> I implemented a part of a script to subtract n months from datetime.
> Basically I subtracted n%12 from year and n//12 from the month adding
> 12 
> months when it goes<=0. Then used try when converting to datetime
> again. 
> So, if the day is for example 31 for a 30 days month it raises a 
> ValuError exception. Then I subtract 1 to day and repeat.
> 
> The code seems too naive and very very complicated!
> What is the best way to achieve this? Any existent module?
> 
> At the very end, what I want is to subtract nx where x can be y, m,
> w, d 
> for respectively years, months, weeks or days.
> 
> I feel I am missing something here ...
> 
> Thanks.
> Paulo
> 

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

Re: F-string usage in a print()

[Paul Bryan]

Try something like:

print(f"Year = {years}, Future value = {future_value}")

On Tue, 2022-05-24 at 21:14 +, Kevin M. Wilson via Python-list
wrote:
> future_value = 0
> for i in range(years):
> # for i in range(months):
>    future_value += monthly_investment
>    future_value = round(future_value, 2)
>    # monthly_interest_amount = future_value * monthly_interest_rate
>    # future_value += monthly_interest_amount
>    # display the result
>    print(f"Year = ", years + f"Future value = \n", future_value)When
> joining a string with a number, use an f-string otherwise, code a
> str() because a implicit convert of an int to str causes a
> TypeError!Well...WTF! Am I not using the f-string function
> correctly...in the above line of code???
> Caddy Man
> 
> Good sense makes one slow to anger, and it is his glory tooverlook an
> offense.
> 
> Proverbs 19:11
> 

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

Re: Non-deterministic set ordering

[Paul Bryan]

This may explain it:
https://stackoverflow.com/questions/27522626/hash-function-in-python-3-3-returns-different-results-between-sessions

On Mon, 2022-05-16 at 04:20 +0100, Rob Cliffe via Python-list wrote:
> 
> 
> On 16/05/2022 04:13, Dan Stromberg wrote:
> > 
> > On Sun, May 15, 2022 at 8:01 PM Rob Cliffe via Python-list 
> >  wrote:
> > 
> >     I was shocked to discover that when repeatedly running the
> > following
> >     program (condensed from a "real" program) under Python 3.8.3
> > 
> >     for p in { ('x','y'), ('y','x') }:
> >      print(p)
> > 
> >     the output was sometimes
> > 
> >     ('y', 'x')
> >     ('x', 'y')
> > 
> >     and sometimes
> > 
> >     ('x', 'y')
> >     ('y', 'x')
> > 
> >     Can anyone explain why running identical code should result in
> >     traversing a set in a different order?
> > 
> > 
> > Sets are defined as unordered so that they can be hashed internally
> > to 
> > give O(1) operations for many tasks.
> > 
> > It wouldn't be unreasonable for sets to use a fixed-by-arbitrary 
> > ordering for a given group of set operations, but being
> > unpredictable 
> > deters developers from mistakenly assuming they are ordered.
> > 
> > If you need order, you should use a tuple, list, or something like 
> > https://grantjenks.com/docs/sortedcontainers/sortedset.html
> Thanks, I can work round this behaviour.
> But I'm curious: where does the variability come from?  Is it
> deliberate 
> (as your answer seems to imply)?  AFAIK the same code within the
> *same 
> run* of a program does produce identical results.
> Best wishes
> Rob Cliffe

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

Re: .0 in name

[Paul Bryan]

On Fri, 2022-05-13 at 22:02 +, Avi Gross via Python-list wrote:

> So why you wonder where it is documented that variables cannot be
> what you feel like is a bit puzzling! 

I had just assumed on good faith that the request to the documentation
would be so that the OP could determine what is valid identifier
syntax.

Paul


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

Re: .0 in name

[Paul Bryan]

On Sat, 2022-05-14 at 00:47 +0800, bryangan41 wrote:

> May I know (1) why can the name start with a number?

The name of an attribute must be an identifier. An identifier cannot
begin with a decimal number.

> (2) where in the doc is it?!

https://docs.python.org/3/reference/lexical_analysis.html#identifiers

Paul

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

[Python-announce] PyCA cryptography 37.0.2

[Paul Kehrer]

PyCA cryptography 37.0.2 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v37-0-2):
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.0.3.
* Added a constant needed for an upcoming pyOpenSSL release.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA bcrypt 3.2.1 released

[Paul Kehrer]

PyCA bcrypt 3.2.1 has been released to PyPI. Bcrypt provides
modern(-ish) password hashing using, unsurprisingly, the bcrypt
algorithm.

Changelog:
* Added support for compilation on z/OS
* The next release of bcrypt will be 4.0 and it will require Rust at
compile time, for users building from source. There will be no
additional requirement for users who are installing from wheels. Users
on most platforms will be able to obtain a wheel by making sure they
have an up to date pip. The minimum supported Rust version will be
1.56.0.
* This will be the final release for which we ship manylinux2010
wheels. Going forward the minimum supported manylinux ABI for our
wheels will be manylinux2014. The vast majority of users will continue
to receive manylinux wheels provided they have an up to date pip.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 37.0.1 released

[Paul Kehrer]

PyCA cryptography 37.0.0 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v37-0-1):
* Fixed an issue where parsing an encrypted private key with the
public loader functions would hang waiting for console input on
OpenSSL 3.0.x rather than raising an error.
* Restored some legacy symbols for older pyOpenSSL users. These will
be removed again in the future, so pyOpenSSL users should still
upgrade to the latest version of that package when they upgrade
cryptography.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[Python-announce] PyCA cryptography 37.0.0 released

[Paul Kehrer]

PyCA cryptography 37.0.0 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v37-0-0):
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.0.2.
* BACKWARDS INCOMPATIBLE: Dropped support for LibreSSL 2.9.x and
3.0.x. The new minimum LibreSSL version is 3.1+.
* BACKWARDS INCOMPATIBLE: Removed signer and verifier methods from the
public key and private key classes. These methods were originally
deprecated in version 2.0, but had an extended deprecation timeline
due to usage. Any remaining users should transition to sign and
verify.
* Deprecated OpenSSL 1.1.0 support. OpenSSL 1.1.0 is no longer
supported by the OpenSSL project. The next release of cryptography
will be the last to support compiling with OpenSSL 1.1.0.
* Deprecated Python 3.6 support. Python 3.6 is no longer supported by
the Python core team. Support for Python 3.6 will be removed in a
future cryptography release.
* Deprecated the current minimum supported Rust version (MSRV) of
1.41.0. In the next release we will raise MSRV to 1.48.0. Users with
the latest pip will typically get a wheel and not need Rust installed,
but check Installation for documentation on installing a newer rustc
if required.
* Deprecated CAST5, SEED, IDEA, and Blowfish because they are legacy
algorithms with extremely low usage. These will be removed in a future
version of cryptography.
* Added limited support for distinguished names containing a bit string.
* We now ship universal2 wheels on macOS, which contain both arm64 and
x86_64 architectures. Users on macOS should upgrade to the latest pip
to ensure they can use this wheel, although we will continue to ship
x86_64 specific wheels for now to ease the transition.
* This will be the final release for which we ship manylinux2010
wheels. Going forward the minimum supported manylinux ABI for our
wheels will be manylinux2014. The vast majority of users will continue
to receive manylinux wheels provided they have an up to date pip. For
PyPy wheels this release already requires manylinux2014 for
compatibility with binaries distributed by upstream.
* Added support for multiple OCSPSingleResponse in a OCSPResponse.
* Restored support for signing certificates and other structures in
X.509 with SHA3 hash algorithms.
* TripleDES is disabled in FIPS mode.
* Added support for serialization of PKCS#12 CA friendly names/aliases
in serialize_key_and_certificates()
* Added support for 12-15 byte (96 to 120 bit) nonces to AESOCB3. This
class previously supported only 12 byte (96 bit).
* Added support for AESSIV when using OpenSSL 3.0.0+.
* Added support for serializing PKCS7 structures from a list of
certificates with serialize_certificates.
* Added support for parsing RFC 4514 strings with from_rfc4514_string().
* Added AUTO to PSS. This can be used to verify a signature where the
salt length is not already known.
* Added DIGEST_LENGTH to PSS. This constant will set the salt length
to the same length as the PSS hash algorithm.
* Added support for loading RSA-PSS key types with
load_pem_private_key() and load_der_private_key(). This functionality
is limited to OpenSSL 1.1.1e+ and loads the key as a normal RSA
private key, discarding the PSS constraint information.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?

[Paul Bryan]

I think because minutes and hours can easily be composed by multiplying
seconds. days is separate because you cannot compose days from seconds;
leap seconds are applied to days at various times, due to
irregularities in the Earth's rotation.

On Thu, 2022-04-14 at 15:38 +0200, Loris Bennett wrote:
> "Loris Bennett"  writes:
> 
> > Hi,
> > 
> > With Python 3.9.2 I get
> > 
> >   $ import datetime
> >   $ s = "1-00:01:01"
> >   $ t = datetime.datetime.strptime(s, "%d-%H:%M:%S")
> >   $ d = datetime.timedelta(days=t.day, hours=t.hour,
> > minutes=t.minute, seconds=t.second)
> >   $ d.days
> >   1
> >   $ d.seconds
> >   61
> >   $ d.minutes
> >   AttributeError: 'datetime.timedelta' object has no attribute
> > 'minutes'
> > 
> > Is there a particular reason why there are no attributes 'minutes'
> > and
> > 'hours and the attribute 'seconds' encompasses is the entire
> > fractional
> > day?
> 
> That should read:
> 
>   Is there a particular reason why there are no attributes 'minutes'
> and
>   'hours' and the attribute 'seconds' encompasses the entire
> fractional
>   day?
> 
> > Cheers,
> > 
> > Loris
> -- 
> Dr. Loris Bennett (Herr/Mr)
> ZEDAT, Freie Universität Berlin Email
> loris.benn...@fu-berlin.de

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

[issue47257] add methods to get first and last elements of a range

[paul rubin]

paul rubin  added the comment:

Oh nice, I didn't realize you could do that.  len(range) and bool(range) (to 
test for empty) also work.  Ok I guess this enhancement is not needed.  I will 
close ticket, hope that is procedurally correct, otherwise feel free to fix.  
Thanks.

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

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

[issue47257] add methods to get first and last elements of a range

[paul rubin]

New submission from paul rubin :

Inspired by a question on comp.lang.python about how to deal with an int set 
composed of integers and ranges.  Range objects like range(1,5,2) contain 
start, stop, and step values, but it's messy and potentially tricky to get the 
actual first and last values of the range.  Examples:

range(1,5,2) - first = 1, last = 3

range (5, 1, 2) - range is empty, first = last = None

range(5, 1, -1) - first is 5, last is 2

Note in the case where the range is not empty, you can get the "last" by a 
messy calculation but it's easier to pick the first element from the reverse 
iterator.  But then you might forget to catch the stopiteration exception in 
the case that the list is empty.  The same goes for the first element, roughly. 
 And constructing the iterators just to pick one element seems like unnecessary 
overhead.

So it is better to have actual methods for these, with type Optional[int].  
Then mypy should remind you to check for the empty case if you forget.

--
messages: 416962
nosy: phr
priority: normal
severity: normal
status: open
title: add methods to get first and last elements of a range
type: enhancement

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

[issue47228] Document that naïve datetime objects represent local time

[Paul Ganssle]

New submission from Paul Ganssle :

Currently, the `datetime` documentation has this to say about naïve datetimes:

> A naive object does not contain enough information to unambiguously locate 
> itself relative to other date/time objects. Whether a naive object represents 
> Coordinated Universal Time (UTC), local time, or time in some other timezone 
> is purely up to the program, just like it is up to the program whether a 
> particular number represents metres, miles, or mass. Naive objects are easy 
> to understand and to work with, at the cost of ignoring some aspects of 
> reality.

This was accurate in Python 2.7, but as of Python 3, the picture is a bit more 
nuanced. `.astimezone()` and `.timestamp()` work for naïve datetimes, but they 
are treated as *system local times*. It is no longer really appropriate to use 
a naïve datetime to a datetime in any specific concrete time zone — instead, 
they should be considered either abstract datetimes for the purposes of 
calendar calculations, or they should be considered as representing the 
realization of that abstract datetime *in the current system locale*. This new 
behavior is referenced in, for example, the warning in `.utcnow()`: 
https://docs.python.org/3.10/library/datetime.html#datetime.datetime.utcnow

We make reference to this in the documentation for `.timestamp()`: 
https://docs.python.org/3.10/library/datetime.html#datetime.datetime.timestamp 
and in `.astimezone()`: 
https://docs.python.org/3.10/library/datetime.html#datetime.datetime.astimezone,
 but the top level explanation makes no reference to it.

I have written a blog post about *why* this is the case: 
https://blog.ganssle.io/articles/2022/04/naive-local-datetimes.html and made 
reference to this behavior in an earlier blog post about `utcnow`: 
https://blog.ganssle.io/articles/2019/11/utcnow.html, but I think it would be a 
good idea to revamp the official documentation to reflect this change in status 
(12 years or so after the change…)

--
assignee: p-ganssle
components: Documentation
messages: 416778
nosy: belopolsky, p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: Document that naïve datetime objects represent local time
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9

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

[issue47207] Switch datetime docstrings / documentation to using "Returns" rather than "Return"?

[Paul Ganssle]

New submission from Paul Ganssle :

In bpo-9305, Fred Drake recommends preferring `Returns ...` over the imperative 
`Return ...`: https://bugs.python.org/issue9305#msg110912

Currently we're pretty consistent about `Return ...`, which is consistent with 
PEP 257: https://peps.python.org/pep-0257/

That said, I actually think "Returns ..." sounds much better in the 
documentation, and I'd be happy to see it changed if others agree.

I have spun this off from bpo-9305 so that we can unblock 
https://github.com/python/cpython/pull/31697.

--
assignee: docs@python
components: Documentation
messages: 416628
nosy: belopolsky, docs@python, fdrake, p-ganssle, slateny
priority: normal
severity: normal
status: open
title: Switch datetime docstrings / documentation to using "Returns" rather 
than "Return"?
versions: Python 3.11

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

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

[Paul Ganssle]

Paul Ganssle  added the comment:

I think this approach is probably the best we can do, but I could also imagine 
that users might find it to be confusing behavior. I wonder if there's any 
informal user testing we can do?

I guess the ISO 8601 spec does call "Z" the "UTC designator", so 
`use_utc_designator` seems like approximately the right name. My main 
hesitation with this name is that I suspect users may think that 
`use_utc_designator` means that they *unconditionally* want to use `Z` — 
without reading the documentation (which we can assume 99% of users won't do) — 
you might assume that `dt.isoformat(use_utc_designator=True)` would translate 
to `dt.astimezone(timezone.utc).replace(tzinfo=None).isoformat() + "Z"`.

A name like `utc_as_z` is definitely less... elegant, but conveys the concept a 
bit more clearly. Would be worth throwing it to a poll or something before 
merging.

--

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

[issue47170] py launcher on windows opens new terminal window when parsing python script with shebang

[Paul Moore]

Paul Moore  added the comment:

This is Windows (shell) behaviour. To avoid this, you need to add the .py 
extension to the PATHEXT environment variable.

--

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

[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

> Awesome, thanks! I'll give it a try later today or tomorrow.

I have applied the patch and the problem seems to have been fixed. \o/

--

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

[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

Awesome, thanks! I'll give it a try later today or tomorrow.

--

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

[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

Hi Serhiy!

> The simple fix is to add UnicodeEncodeError to "except LookupError". But 
> there may be other places where we can get a similar error. They should be 
> fixed too.

I would be very interested to test this as this issue currently blocks my use 
of offlineimap.

Would you mind creating a proof-of-concept patch for me if it's not too much 
work?

Thanks!

--

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

Re: for convenience

[Paul St George]

On 22/03/2022 18.04, dn wrote:

> and thank you - it is refreshing, if not enervating, to receive feedback
> on efforts-expended!
> 
> You will also notice, that now you understand the id() stuff, the
> tag-team effect between @Chris and I (which we have often played, albeit
> not by-design), now makes sense as an whole (if you didn't quite follow,
> earlier).
> 
> 
> My research-topic is Cognitive Psychology (how we learn - albeit not
> usually in Python). I found this conversation useful, and may well apply
> it as an example (with your permission, and suitably anonymised) - one
> doesn't need to be a 'computer person' to follow the logic and thus
> realise the dissonance!
> 
> While learning (this part of) Python and adding to 'previous
> experience', you formed a "mental-model" of how things work (just as we
> all do). However, when it came time to implement this knowledge:
> 
> - you created a 'situation'
> - (all) things didn't 'work' (which also required realisation)
> - you analysed and rationalised (but noted inconsistency)
> - you asked a question (which many of us quickly understood)
> - you've learned/corrected
> 
> 
> The 'issue' is *not* a fault on your part, nor (necessarily) a lack of
> learning or a lack of effort. So, no criticism from me!
> 
> The (under-lying) lesson, is that we (as trainers, but with application
> to all helpers, pair-programmers, mentors, documentation-writers, et al
> - working with less-experienced colleagues) shouldn't spout a whole load
> of 'facts', 'rules', and formulae/s - which we expect to be committed to
> memory. We need to help form a 'correct' mental-model ("correct" being
> defined by the Python interpreter and 'the Python gods' who build it -
> big "thank you" to them!).
> 
> Accordingly, my criticism of tests/exams which require recitation of
> facts ("parroting"), compared with "mastery" (can you actually DO what
> is being asked). More importantly, and finally getting to the point:
> 'tests' should be defined to reveal these (personal) 'quirks' of
> learning/understanding, which led to a 'faulty' mental-model!
> 
> Your rationale made sense, was logical and understandable. How are you
> to know that Python deems it 'wrong'? (until a 'test' shows you!)
> 
> The 'interest' should not be on the people who, and all the 'answers'
> which, were 'correct'. What is more informative, is why someone (aside
> from guessing, ie intelligent, reasonable, after learning the material,
> exerting effort...) got it 'wrong' - but thought his/her path was true!
> -- 
> Regards,
> =dn


Wow, this is super interesting. You have my permission, and please feel free to 
contact me offline if you want to ask anything.

Yes, I had noticed the tandem with @Chris. I think I needed both! I already 
have a folder on my Mac called ‘Cameron’. Perhaps I now need an additional 
folder. Then I can ask my question about whether Python grows to be more like 
its programmers, or do programmers learn to think Pythonically?


—
Paul St George

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

Re: for convenience

[Paul St George]

On 21/03/2022 17.47, Avi Gross wrote:

> So, I ask Paul what other language than python he has used before, just out 
> of curiosity.

The other language I have used (and often) is Processing. Before that, and a 
long time ago, Lingo. 

—
Paul






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

Re: for convenience

[Paul St George]

On 21/03/2022 18.02, Cameron Simpson wrote:

> On 21Mar2022 22:12, Paul St George  wrote:
> >When I am writing code, I often do things like this:
> >
> >context = bpy.context  # convenience
> >
> >then whenever I need bpy.context, I only need to write context
> >
> >
> >Here’s my question:
> >
> >When I forget to use the convenient shorter form
> >
> >why is bpy.context not interpreted as bpy.bpy.context?
> 
> Because it still has its original meaning. You haven't changed the 
> meaning of the word "context" in any position, you have simply made a 
> module level name "context" referring to the same object to which 
> "bpy.context" refers.
> 
> So your module global namespace contains, initially, "bpy". Then you 
> assign:
> 
> context = bpy.context
> 
> and now your module global namespace contains "bpy" and "context". But 
> "bpy.context" is still what it was, because "bpy" is an object and you 
> have done nothing to its ".context" attribute.
> 
> Consider this code:
> 
> class O:
> pass
> 
> o = O()
> o.x = 3
> 
> x = o.x
> 
> print(x)
> print(o.x)
> 
> I expect to see "3" twice. What do you expect?
> 
> "bpy" is no different to "o" - it's just a name.


Thanks Cameron,
What did I expect? Well, I expected to see  "3” twice, but I did not understand 
why. Now I do!

—
Thanks,
Paul








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

Re: for convenience

[Paul St George]

On 21/03/2022 18.04, dn wrote:

> On 22/03/2022 10.17, Chris Angelico wrote:
> > On Tue, 22 Mar 2022 at 08:13, Paul St George  > <https://mail.python.org/mailman/listinfo/python-list>> wrote:
> >>
> >>
> >> When I am writing code, I often do things like this:
> >>
> >> context = bpy.context  # convenience
> >>
> >> then whenever I need bpy.context, I only need to write context
> >>
> >>
> >> Here’s my question:
> >>
> >> When I forget to use the convenient shorter form
> >>
> >> why is bpy.context not interpreted as bpy.bpy.context?
> >>
> > 
> > I don't understand the question. When you do that "for convenience"
> > assignment, what you're doing is creating a local variable named
> > "context" which refers to the same thing that bpy.context does (or did
> > at the time of the assignment, but presumably you only do this when
> > bpy.context won't get reassigned). It has no effect on any other name.
> > There's no magic happening here - it's just assignment to the name
> > context, like anything else.
> > 
> > What are you expecting to happen here?
> 
> 
> It's the way Python works.
> 
> try:
> 
> context = bpy.context  # convenience
> print( id(context), id(bpy.context) )
> 
> Remember that the 'relationship' between the two is established at
> run-time and at the data/address 'level' - and not at compile-time. Thus
> "context" points to a memory location, and does not 'stand for'
> "bpy.context" anywhere other than in your mind.
> 
> (which is why we often need to use a copy() when we want 'separate data'
> - see also the 'counters' Python uses to manage "garbage collection")
> 
> -- 
> Regards,
> =dn


Thanks dn,
I did exactly as you suggested.

import bpy

context = bpy.context  # convenience variable
print( id(context), id(bpy.context) )

4932508928 4932508928

The two are the same, and that makes it crystal clear. And, as a bonus you have 
explained a use of copy().

—
Thanks,
Paul




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

Re: for convenience

[Paul Bryan]

No, nor did I suggest that you did. `context` is presumably an
attribute in the `bpy` module, for which you are creating a `context`
attribute in your module.

On Mon, 2022-03-21 at 22:31 +0100, Paul St George wrote:
> Hi,
> I do not (knowingly) have a module called ‘context'.
> 
> 
> 
> 
> > On 21 Mar 2022, at 22:24, Paul Bryan  wrote:
> > 
> > Assuming `bpy` is a module, you're creating a new attribute in your
> > module, `context`, that contains a reference to the same object
> > that is referenced in the `context` attribute in the `bpy` module.
> > 
> > On Mon, 2022-03-21 at 22:12 +0100, Paul St George wrote:
> > > 
> > > When I am writing code, I often do things like this:
> > > 
> > > context = bpy.context  # convenience
> > > 
> > > then whenever I need bpy.context, I only need to write context
> > > 
> > > 
> > > Here’s my question:
> > > 
> > > When I forget to use the convenient shorter form 
> > > 
> > > why is bpy.context not interpreted as bpy.bpy.context?
> > > 
> > > 
> > > —
> > > Paul St George
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> 

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

Re: for convenience

[Paul St George]

Hi,
I do not (knowingly) have a module called ‘context'.




> On 21 Mar 2022, at 22:24, Paul Bryan  wrote:
> 
> Assuming `bpy` is a module, you're creating a new attribute in your module, 
> `context`, that contains a reference to the same object that is referenced in 
> the `context` attribute in the `bpy` module.
> 
> On Mon, 2022-03-21 at 22:12 +0100, Paul St George wrote:
>> 
>> When I am writing code, I often do things like this:
>> 
>> context = bpy.context  # convenience
>> 
>> then whenever I need bpy.context, I only need to write context
>> 
>> 
>> Here’s my question:
>> 
>> When I forget to use the convenient shorter form 
>> 
>> why is bpy.context not interpreted as bpy.bpy.context?
>> 
>> 
>> —
>> Paul St George
>> 
>> 
>> 
>> 
>> 
> 

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

Re: for convenience

[Paul Bryan]

Assuming `bpy` is a module, you're creating a new attribute in your
module, `context`, that contains a reference to the same object that is
referenced in the `context` attribute in the `bpy` module.

On Mon, 2022-03-21 at 22:12 +0100, Paul St George wrote:
> 
> When I am writing code, I often do things like this:
> 
> context = bpy.context  # convenience
> 
> then whenever I need bpy.context, I only need to write context
> 
> 
> Here’s my question:
> 
> When I forget to use the convenient shorter form 
> 
> why is bpy.context not interpreted as bpy.bpy.context?
> 
> 
> —
> Paul St George
> 
> 
> 
> 
> 

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

for convenience

[Paul St George]

When I am writing code, I often do things like this:

context = bpy.context  # convenience

then whenever I need bpy.context, I only need to write context


Here’s my question:

When I forget to use the convenient shorter form 

why is bpy.context not interpreted as bpy.bpy.context?


—
Paul St George





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

[issue22628] Idle: Tree lines are spaced too close together.

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

This is still/again broken, probably because the "fixed" version still 
hard-codes all of the geometry values and these will certainly not be correct 
for all combinations of display dpi, font configuration, etc.

Instead, `TreeNode.draw` and `TreeNode.drawtext` (at least) need to consider 
the size of the children and space them accordingly.

--
nosy: +exarkun
resolution: fixed -> 
status: closed -> open

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

[Python-announce] PyCA cryptography 36.0.2 released

[Paul Kehrer]

PyCA cryptography 36.0.2 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+, and PyPy3.

Changelog (https://cryptography.io/en/latest/changelog/#v36-0-2):
* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 1.1.1n.

-Paul Kehrer (reaperhulk)
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[issue46566] Support -3.11-arm64 in py.exe launcher

[Paul Moore]

Paul Moore  added the comment:

> as well as potentially being able to be a script or .pyz launcher with a 
> simple rename.

Would it be possible to also make the launcher work when prepended to a 
zipfile? That's a really useful use-case (make a zipapp automatically runnable, 
but still a single file) that at the moment needs a 3rd party launcher (Vinay's 
simple-launcher project).

If not, then that's fine, but if we're already doing a significant rewrite that 
might be a good time to add it.

--

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

[issue47002] argparse - "expected one argument" when used -: in argument

[paul j3]

paul j3  added the comment:

'-1' and '-1.23' are recognized as numbers, and treated as arguments.  '-1' 
requires some special handling because it is allowed as a flag, as in

parser.add_argument('-1','--one')

'-1:00' on the other hand is no different from a string like '-foo'.  Default 
is to parse it as a flag.  If you don't get this error

argument -f: expected one argument

you are likely to get:

error: unrecognized arguments: -1:23

This can probably be closed as a duplicate of:

https://bugs.python.org/issue9334
argparse does not accept options taking arguments beginning with dash 
(regression from optparse)

--

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

[issue46682] python 3.10 Py_Initialize/Py_Main std path no longer includes site-packages

[Paul Jaggi]

New submission from Paul Jaggi :

Have the following simple program:
#include 
#include 

using namespace std;

int main(int argc, char** argv) {
  wchar_t* args[argc];
  for(int i = 0; i < argc; ++i) {
args[i] = Py_DecodeLocale(argv[i], nullptr);
  }

  Py_Initialize();
  const int exit_code = Py_Main(argc, args);
  cout << "Exit code: " << exit_code << endl;
  cout << "press any key to exit" << endl;
  cin.get();
  return 0;
}

When you run this program and in the console:
import sys
sys.path

for Python versions between 3.7-3.9, you get the installed python site-packages 
by default.  For Python 3.10, you don't.  This happens on both windows and Mac. 
 Is this an intentional change?

--
components: C API
messages: 412848
nosy: pjaggi1
priority: normal
severity: normal
status: open
title: python 3.10 Py_Initialize/Py_Main std path no longer includes 
site-packages
type: behavior
versions: Python 3.10

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

[issue46628] Can't install YARL

[Paul Koning]

Paul Koning  added the comment:

Thanks, I'll pass the word to the yarl and aiohttp team (both have this issue).

--

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

[issue46628] Can't install YARL

[Paul Koning]

Paul Koning  added the comment:

The only dependency mentioned by the yarl documentation is multidict and 
installing that makes no difference.  I see I can tell yarl to build a 
pure-python version to avoid compiling stuff.  If I do that it installs.  But 
what I actually wanted to do is install aiohttp, and that step fails with the 
exact same error message.

Given that it works in 3.10 but fails in 3.11a4, it does seem there is 
something about the new code that is involved here.

--

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

[issue46628] Can't install YARL

[Paul Koning]

New submission from Paul Koning :

Trying to install "aiohttp" with pip I get a compile error installing "yarl".  
I get the same error when I install just that module.  But it installs fine on 
3.10.  This is on an Apple M1 (ARM64) machine.

--
components: macOS
files: yarl.log
messages: 412453
nosy: ned.deily, pkoning, ronaldoussoren
priority: normal
severity: normal
status: open
title: Can't install YARL
type: compile error
versions: Python 3.11
Added file: https://bugs.python.org/file50602/yarl.log

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

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

[Paul Ganssle]

Paul Ganssle  added the comment:

I don't think it's necessary to add a feature to `isoformat()` just for the 
purpose of being able to add the corresponding parser, particularly when the 
plan is to implement a much broader ISO 8601 parser for Python 3.11 (I've done 
most of the implementation in C already, I can share the progress I've made, 
particularly if someone else wants to pick up the baton there before I get back 
to it).

That said, I think it's useful for `isoformat()` to be able to output UTC times 
as "Z", so we may as well do that as part of 3.11 anyway. I think that's a 
separate issue to discuss, so I've created bpo-46614 to hammer out the details.

--
versions: +Python 3.11 -Python 3.8

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

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

[Paul Ganssle]

New submission from Paul Ganssle :

As part of bpo-35829, it was suggested that we add the ability to output the 
"Z" suffix in `isoformat()`, so that `fromisoformat()` can both be the exact 
functional inverse of `isoformat()` and parse datetimes with "Z" outputs. I 
think that that's not a particularly compelling motivation for this, but I also 
see plenty of examples of `datetime.utcnow().isoformat() + "Z"` out there, so 
it seems like this is a feature that we would want to have *anyway*, 
particularly if we want to deprecate and remove `utcnow`.

I've spun this off into its own issue so that we can discuss how to implement 
the feature. The two obvious questions I see are:

1. What do we call the option? `use_utc_designator`, `allow_Z`, `utc_as_Z`?
2. What do we consider as "UTC"? Is it anything with +00:00? Just 
`timezone.utc`? Anything that seems like a fixed-offset zone with 0 offset?

For example, do we want this?

>>> LON = zoneinfo.ZoneInfo("Europe/London")
>>> datetime(2022, 3, 1, tzinfo=LON).isoformat(utc_as_z=True)
2022-03-01T00:00:00Z
>>> datetime(2022, 6, 1, tzinfo=LON).isoformat(utc_as_z=True)
2022-06-01T00:00:00+01:00

Another possible definition might be if the `tzinfo` is a fixed-offset zone 
with offset 0:

>>> datetime.timezone.utc.utcoffset(None)
timedelta(0)
>>> zoneinfo.ZoneInfo("UTC").utcoffset(None)
timedelta(0)
>>> dateutil.tz.UTC.utcoffset(None)
timedelta(0)
>>> pytz.UTC.utcoffset(None)
timedelta(0)

The only "odd man out" is `dateutil.tz.tzfile` objects representing fixed 
offsets, since all `dateutil.tz.tzfile` objects return `None` when `utcoffset` 
or `dst` are passed `None`. This can and will be changed in future versions.

I feel like "If the offset is 00:00, use Z" is the wrong rule to use 
conceptually, but considering that people will be opting into this behavior, it 
is more likely that they will be surprised by `datetime(2022, 3, 1, 
tzinfo=ZoneInfo("Europe/London").isoformat(utc_as_z=True)` returning 
`2022-03-01T00:00:00+00:00` than alternation between `Z` and `+00:00`.

Yet another option might be to add a completely separate function, 
`utc_isoformat(*args, **kwargs)`, which is equivalent to (in the parlance of 
the other proposal) `dt.astimezone(timezone.utc).isoformat(*args, **kwargs, 
utc_as_z=True)`.  Basically, convert any datetime to UTC and append a Z to it. 
The biggest footgun there would be people using it on naïve datetimes and not 
realizing that it would interpret them as system local times.

--
assignee: p-ganssle
components: Library (Lib)
messages: 412384
nosy: belopolsky, brett.cannon, p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: Add option to output UTC datetimes as "Z" in `.isoformat()`
type: enhancement
versions: Python 3.11

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

[issue46228] argparse docs: default for prog= in ArgumentParser() should be basename of argv[0], not argv[0], to match behaviour

[paul j3]

Change by paul j3 :


--
nosy: +paul.j3

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

[issue46101] argparse: using parents & subcommands, options can be ignored

[paul j3]

Change by paul j3 :


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

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

[issue46080] argparse.BooleanOptionalAction with default=argparse.SUPPRESS and help specified raises exception

[paul j3]

Change by paul j3 :


--
nosy: +paul.j3

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

[issue46440] ArgumentParser.parse_args exits on missing required argument with exit_on_error=False

[paul j3]

paul j3  added the comment:

Duplicate of https://bugs.python.org/issue41255

Argparse.parse_args exits on unrecognized option with exit_on_error=False

--
nosy: +paul.j3
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

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

[issue42982] Update suggested number of iterations for pbkdf2_hmac()

[Paul Kehrer]

Paul Kehrer  added the comment:

NIST provides no official guidance on iteration count other than NIST SP 
800-132 Appendix A.2.2, which states "The number of iterations should be set as 
high as can be tolerated for the environment, while maintaining acceptable 
performance."

I can think of no better resource for what constitutes acceptable performance 
at the highest iteration count than popular packages like Django. Django's 
choice (and lack of evidence that they've had any cause to revert due to 
performance issues) argues that 390k iterations is a reasonable number in 2022. 
Certainly the 100k suggested in these docs as of 2013 is no longer best 
practice as we've seen 9 years of computational improvement in the intervening 
time.

I would, additionally, suggest that the documentation recommend the use of 
scrypt where possible over any iteration count of PBKDF2, but increasing the 
iteration count is still a useful improvement to the docs!

--
nosy: +reaperhulk

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

[issue46447] datetime.isoformat() documentation does not point to the risk of using it with naive datetime objects

[Paul Ganssle]

Paul Ganssle  added the comment:

Sorry I missed this! Thank you for taking the time to write this up and to make 
a PR.

Unfortunately, I don't think I agree with the idea of warning about this. The 
warnings about `utcnow` and `utcfromtimestamp` are a problem because `utcnow` 
and `utcfromtimestamp` are intended to represent times in UTC, but they return 
datetimes that actually represent local times in the semantics of modern 
Python. Basically, these functions are dangerous not because they are using 
naïve datetimes, but because they are *mis*using naïve datetimes.

The same can not be said of `.isoformat()`, which is doing the right thing when 
you use `datetime.now().isoformat()`. If you look at Wikipedia's article on ISO 
8601 (which is pretty much the best resource on this, since ISO 8601 is itself 
paywalled and we never should have standardized on a proprietary standard in 
the first place), you'll see it says:

> Local time (unqualified)
> If no UTC relation information is given with a time representation, the time 
> is assumed to be in local time. While it may be safe to assume local time 
> when communicating in the same time zone, it is ambiguous when used in 
> communicating across different time zones.

It may be that for the kind of programming you do, it doesn't make sense to use 
local datetimes in an interchange format — but it is a legitimate use case and 
there are definitely situations where it is very much the right thing to do, so 
I don't think we should warn against it in the `datetime.isoformat` 
documentation.

There is *might* be some case for warning about this or something like it in 
the `datetime.now` documentation. The major use cases for naïve datetimes are 
things where you are working with system time or things where you are working 
with dates in the future — you don't want to specify that some event is going 
to happen at 2030-03-31T12:00Z if the actual event is planned for April 1, 2030 
at 13:00 *London time*, because if, between now and then, the UK decides to 
cancel DST or move the start back a week, the event you've stored as a UTC time 
now longer represents what it was intended to represent. In a lot of cases 
`datetime.now()` will just be used as "what time is it now", which is not 
subject to that particular problem because by the time the datetime gets stored 
or used, `datetime.now()` is a date in the *past*, and can safely be converted 
to UTC for all time.

Of course, if you are consuming a bunch of event dates stored in local time and 
you want to compare them to the current time, then `datetime.now()` would be 
appropriate. Similarly if you want to display the current time to a user on a 
given system (rather than logging or storing it), it would also make sense to 
do things like `print(datetime.now().isoformat())`, so there are definitely 
also legitimate use cases for `datetime.now()`.

I'm inclined to say that we should *not* have a warning on `datetime.now()`, 
because we will  give people warning fatigue if we do, and we definitely want 
people to see `now()` as the correct alternative to `utcnow()`. I am more 
sympathetic to rewording the `.now()` documentation to make it clear that this 
will be a naïve time *representing the current time in the system local time 
zone* if `None` is passed (i.e. rewording or appending to the "If optional 
argument `tz`" paragraph).

--
nosy: +belopolsky, p-ganssle

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

[issue46159] Segfault when using trace functions in 3.11a3

[Paul Kehrer]

Paul Kehrer  added the comment:

Changes in ABI don't seem to be the likely culprit since the Dockerfile 
provided can demonstrate this bug and has no caching that would result in 
obtaining alpha2-based binaries.

--

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

[issue29964] [doc] %z directive has no effect on the output of time.strptime

[Paul Pinterits]

Change by Paul Pinterits :


--
nosy:  -Paul Pinterits

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

[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset

[John Paul Adrian Glaubitz]

John Paul Adrian Glaubitz  added the comment:

I'm running into exactly this issue when using 'offlineimap' which is written 
in Python.

--
nosy: +glaubitz

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

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

[Paul Campbell]

Paul Campbell  added the comment:

Victor: The changes in the main branch gets me past this issue without having 
to make additional changes.

--

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

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

[Paul Campbell]

Paul Campbell  added the comment:

> In Python, we are trying to provide a same C API on all platforms. If "struct 
> stat" is no longer considered as portable, IMO we should attempt to avoid it, 
> at least in the public C API.

Microsoft provides stat and struct stat, but they prepend the names with an 
underscore. So functions like stat are named _stat and struct stat is named 
struct _stat, etc. Not sure if pros/cons of using such functions are though. 
Seems it would go back to depending on some type nonstandard python macro to 
translate between the two during build.

--

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

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

[Paul Campbell]

Paul Campbell  added the comment:

Hi Victor, I was trying to compile with clang on Windows 10. I will try to pull 
your 3.11 changes and test. Sorry to cause so much churn. It looked to me like 
a simple issue that was missed, probably because whatever was trying to compile 
was not normally compiled on Windows. I was not trying to make a lot of work to 
support a new platform :)

--

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

Re: A Newspaper for Python Mailing Lists

[Paul Bryan]

Subscribed. ️

On Wed, 2022-01-12 at 00:35 +0400, Abdur-Rahmaan Janhangeer wrote:
> Added RSS:
> 
> 2.0 unless later versions have some advantages:
> 
> https://pyherald.com/rss.xml
> 
> Kind Regards,
> 
> Abdur-Rahmaan Janhangeer
> about | blog 
> github
> Mauritius
> 

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

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

[Paul Campbell]

Paul Campbell  added the comment:

I was trying to build python core (-DMS_WINDOWS -DPy_BUILD_CORE). I was using 
clang, which I think is unsupported looking at Windows doc. After looking at 
the issue though, it seemed that it was just some slight mistake which is why I 
filed the bug.

clang version 13.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix

I can test to see if it fixes the immediate build problem, but I still find 
your fix not quite addressing the issue which I initially tried to create a 
patch for. Someone has already developed a shim here for Windows and it just 
was not used properly. `_Py_stat_struct` is a define which either evaluates to 
`stat` on non-Windows systems or a compatibility structure on Windows. Simply 
replacing the use of `struct stat` with `struct _Py_stat_struct` should solve 
the issue.

--

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

[issue46057] argparse: embedded groups may prevent options from being in help output

[paul j3]

paul j3  added the comment:

"I tried to create a group hierarchy in a way that I can pass the 
responsibility of argument validation to the argument parser." 

I looked at your example in:

https://bugs.python.org/issue46058

The many levels of nesting groups was confusing, but now I realize that by 
nesting argument_groups in a mutually_exlusive_group you were try to implement 
some sort of any/all group within the xor group.  

This cannot be done within argparse.  Mutually_exclusive only implements a flat 
xor.  Argument_groups are used for help display, but play no role in parsing.

Some years ago I explored the use of nest parsing groups:

https://bugs.python.org/issue11588
Add "necessarily inclusive" groups to argparse

I was trying to allow for nested groups that implemented all logical options - 
xor, or, and, not.  Defining such groups wasn't hard.  And I think I got the 
testing logic working right.  But usage display required too big of a change to 
the formatter, and left too many loose ends.  So I have let that languish.

Now I recommend focusing on doing the testing after parsing.  Use meaningful 
defaults where possible, and use `is None` to test whether a users has provided 
a value or not.

--

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

[issue46101] argparse: using parents & subcommands, options can be ignored

[paul j3]

paul j3  added the comment:

This patch should be rejected.

By using `common_opts_parser` as parent to both the main and subparsers, you 
have defined the same argument in both.

By a long standing patch, the value assigned in the subparser has precedence 
(whether it's the default or user supplied).

https://bugs.python.org/issue9351
argparse set_defaults on subcommands should override top level set_defaults

Partial retraction of this override has been explored, but any changes are 
still up for debate

https://bugs.python.org/issue45235
argparse does not preserve namespace with subparser defaults

The bottom line is that we should not try to define the same argument (or more 
specifically the same `dest`) in both main and subparsers.  Duplicate flags are 
ok.  

But resolving the conflicting values should be done after parsing.  Some users 
will want to give priority to the main parser's values, others to the 
subparser's.  Or their own defaults.  argparse cannot handle all cases cleanly.

--

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

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[Paul Ganssle]

Paul Ganssle  added the comment:

> from practical experience, it is a whole lot better to not deal with 
> timezones in data processing code at all, but instead only use naive UTC 
> datetime values everywhere, expect when you have to prepare reports or output 
> which has a requirement to show datetime value in local time or some specific 
> timezone.

This is not good advice. It is out of date, and has some significant pitfalls. 
See my blog post on the subject: 
https://blog.ganssle.io/articles/2019/11/utcnow.html

If you are working with `datetime` objects that represent time in a specific 
time zone other than the system local zone, you should probably have them carry 
around a tzinfo object.

> Note also that datetime.now() gives you a naive datetime.  From an API 
> consistency standpoint I think it makes sense that datetime.utcnow() gives a 
> naive datetime.

This... is not accurate. `.now()` gives you the local time; to the extent that 
they represent a date in a time zone at all, naïve time zones represent times 
in the *system local time*, which is why it makes sense for `.now()` to default 
to returning naïve time zones. For example, `datetime.now().timestamp()` will 
give accurate information, whereas `datetime.utcnow().timestamp()` will *not* 
(unless your local zone happens to be UTC or equivalent).

> It would actually be confusing (IMO) for it to return an aware datetime.  I 
> can see why you might disagree, but backward compatibility wins in this case 
> regardless.

As evidenced by this thread, the fact that we have some APIs that return naïve 
datetimes generated by a process that treats them as localized datetimes in 
something other than system local times is actually the source of confusion 

That said, from a backwards compatibility point of view, we simply cannot 
change this. It has been proposed many times and it would be a major breaking 
change for almost no reason. The best we can do is to deprecate the offending 
methods and remove them.

There is more information about the challenge that doing this would present in 
this datetime-SIG thread: 
https://mail.python.org/archives/list/datetime-...@python.org/thread/PT4JWJLYBE5R2QASVBPZLHH37ULJQR43/

I am sympathetic to the idea of removing it, but we would probably want to put 
some optimizations in place for `UTC` first, to make the transition more 
seamless in the few places where there are legitimate uses for `utcnow` and 
`utcfromtimestamp`.

> I would argue that PEP20 should win over backward compatibility, in addition 
> to the points I hinted at above, practicality beats purity

PEP 20 contains a bunch of contradictory advice, and it's not really a binding 
document anyway, so it definitely doesn't "win" over anything, but in this case 
you have it backwards. "Purity" would be making a breaking change for the 
purposes of making the function do what a lot of people think it does, but 
doing so would actually be impractical, because it would cause a lot of work 
for people, and create a lot of ambiguity in what people meant when they wrote 
a given line of code. The practical things to do here would be to either do 
nothing (not break anything that works and try and guide people away from using 
`utcnow` — maybe get a linting rule added to `pylint` to warn against it), or 
to deprecate and remove the function.

--

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

[issue46319] datetime.utcnow() should return a timezone aware datetime

[Paul Ganssle]

Paul Ganssle  added the comment:

Yes, this is the documented behavior, including a warning against using UTC now 
in the documentation!

There is some possibility of removing utcnow entirely as an "attractive 
nuisance", but I suspect that this will lead to much consternation and 
hand-wringing, and there are some legitimate uses for `utcnow`, so I haven't 
made it a high priority to have that particular fight...

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

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

Re: A Newspaper for Python Mailing Lists

[Paul Bryan]

+1 to RSS.

On Sun, 2022-01-09 at 10:28 +0400, Abdur-Rahmaan Janhangeer wrote:
> Well yes XD though LWN covers Py topics well when it wants
> 
> 
> 1. Yes sure, did not expect RSS interest
> 2. Excuse my blunder, will do!
> 
> On Sun, 9 Jan 2022, 01:15 Peter J. Holzer,  wrote:
> 
> > On 2021-12-26 20:40:03 +0400, Abdur-Rahmaan Janhangeer wrote:
> > > I have started a newspaper (not newsletter) focused
> > > on interesting reads on Python mailing lists. Don't tag
> > > on the fact that holiday seasons are the worst times for
> > > launch according to marketing folks, I started this to note
> > > down interesting mails. This might also be a great way to
> > > bring mailing list gems to a wider readership. So, here's
> > > the url https://pyherald.com/
> > 
> > Something like [LWN](https://lwn.net/) for Python? Neat.
> > 
> > Two suggestions:
> > 
> > 1. Could you add an RSS or Atom feed?
> > 
> > 2. CSS «word-break: break-all» seems like a really weird choice for
> >    English language text. If you really want to break words across
> >    lines, use «hyphens: auto».
> > 
> >     hp
> > 
> > --
> >    _  | Peter J. Holzer    | Story must make more sense than
> > reality.
> > > _|_) |    |
> > > >   | h...@hjp.at |    -- Charles Stross, "Creative
> > > > writing
> > __/   | http://www.hjp.at/ |   challenge!"
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> > 

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

[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument

[Paul Campbell]

Change by Paul Campbell :


--
title: _Py_stat using incorrect type for status argument -> _Py_stat and 
_Py_wstat using incorrect type for status argument

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

[issue46303] _Py_stat using incorrect type for status argument

[Paul Campbell]

Change by Paul Campbell :


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

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

[issue46303] _Py_stat using incorrect type for status argument

[Paul Campbell]

Change by Paul Campbell :


--
components: +Build, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type:  -> compile error

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

[issue46303] _Py_stat using incorrect type for status argument

[Paul Campbell]

New submission from Paul Campbell :

While attempting to embed the full cpython source in my application, I found 
that during compilation on Windows, there was a compilation issue due to struct 
stat not being defined. Taking a look at the file cpython/fileutils.h, it seems 
that the type of the status argument should be _Py_stat_struct instead of just 
stat to satisfy compilation for all supported platforms.

--
messages: 410073
nosy: pacampbell
priority: normal
severity: normal
status: open
title: _Py_stat using incorrect type for status argument
versions: Python 3.11

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

[issue34602] python3 resource.setrlimit strange behaviour under macOS

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

My understanding of the resolution of this ticket is that it is still not 
possible to use setrlimit with RLIMIT_STACK to raise the soft stack limit.  Is 
that correct?

In that case, the original bug report still seems valid and unresolved (and 
indeed, I am porting a project from Python 2.7 to Python 3.9 and on macOS it 
fails because it cannot raise the stack limit).

--
nosy: +exarkun

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