[Python-announce] Release of NumPy 1.23.5

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I am pleased to announce the release of
NumPy 1.23.5. NumPy 1.23.5 is a maintenance release that fixes bugs
discovered after the 1.23.4 release and keeps the build infrastructure
current. The Python versions supported for this release are 3.8-3.11.
Wheels can be downloaded from PyPI
; source
archives, release notes, and wheel hashes are available on Github
.

*Contributors*

A total of 7 people contributed to this release.  People with a "+" by
their names contributed a patch for the first time.

   - @DWesl
   - Aayush Agrawal +
   - Adam Knapp +
   - Charles Harris
   - Navpreet Singh +
   - Sebastian Berg
   - Tania Allard


*Pull requests merged*

A total of 10 pull requests were merged for this release.

   - #22489: TST, MAINT: Replace most setup with setup_method (also
   teardown)
   - #22490: MAINT, CI: Switch to cygwin/cygwin-install-action@v2
   - #22494: TST: Make test_partial_iteration_cleanup robust but require
   leak...
   - #22592: MAINT: Ensure graceful handling of large header sizes
   - #22593: TYP: Spelling alignment for array flag literal
   - #22594: BUG: Fix bounds checking for ``random.logseries``
   - #22595: DEV: Update GH actions and Dockerfile for Gitpod
   - #22596: CI: Only fetch in actions/checkout
   - #22597: BUG: Decrement ref count in gentype_reduce if allocated
   memory...
   - #22625: BUG: Histogramdd breaks on big arrays in Windows

Cheers,

Charles Harris
___
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: Passing information between modules

[Dan Kolis]

In a module mostly for this purpose; ( big program means many modules aka files 
):
--
globalIdeas.py
--
# Empty object maker ( M T ) ... get it say it !
class MT():
pass

# IO dot area readier 
def prepIO():

# Prep for general IO use really
dotObjOps.ioSupport = MT()
dotObjOps.ioSupport.sequenceMacro = MT()


-
In Every use module:
-
import globalIdeas as   gi 

so now without burdensome advanced planning, a swap area is not only segregated 
by function
but doesn't overly pollute too much globalism everywhere.

New Idea:
gl.ioSupport.sequencesMacro.newStartupIdea = {}
gl.ioSupport.sequencesMacro.thingToReuse = 14
etc ...

A method in globalIdeas is named like startEverything():
  prepIO()
  prepNext()
  prepSounds()
   etc...

This seems to me amenable to management of large programs in which absolutely 
any shaped objects be created as needed and be RW sharable in orderly fashion, 
etc.

Its important if you read write files to plan ahead and have MT() names in 
surplus before you need them.

I cant see any drawback to this at all. Many program have very legit reasons to 
have universal ideas. This avoids the emotional burden of the' "global KW" ; 
entirely.

Regards,
Daniel B. Kolis









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

Re: Logging

[Cameron Simpson]

On 20Nov2022 12:36, Chris Angelico  wrote:

On Sun, 20 Nov 2022 at 12:27, Cameron Simpson  wrote:

But really, is there any problem which cannot be solved with a
decorator? I've even got a @decorator decorator for my decorators.


Do you have a @toomanydecorators decorator to reduce the number of
decorators you need to decorate your decorators?


Apparently not :-)

@classmethod
@pfx_method
@promote
@typechecked
def promote(cls, policy, epoch: Optional[Epoch] = None, **policy_kw):

and there aren't even any @require decorators on that one (from the 
excellent icontract package).


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

Re: Superclass static method name from subclass

[Thomas Passin]

On 11/13/2022 7:27 AM, Axy via Python-list wrote:

On 11/11/2022 16:21, Ian Pilcher wrote:

Is it possible to access the name of a superclass static method, when
defining a subclass attribute, without specifically naming the super-
class?


A instance's __bases__ attribute is a sequence that contains all its 
base classes. So:


class A:
@staticmethod
def double(n):
return 2 * n

class B(A):
def parent_method(self, n):
par = self.__class__.__bases__[0]  # For single inheritance
return par.double(n)

b = B()
print(b.parent_method(3))  # 6

#  or
print(b.__class__.__bases__[0].double(4)) # 8



Contrived example:

  class SuperClass(object):
  @staticmethod
  def foo():
  pass

  class SubClass(SuperClass):
  bar = SuperClass.foo
    ^^

Is there a way to do this without specifically naming 'SuperClass'?

There is, but it's weird. I constructed classes from yaml config so I 
did not even know the name of super class but I wanted similar things 
for my clabate templates and I implemented superattr() which works for me:


class BasePage:

     body = 'Hello'

class MySpecificPage(BasePage):

     body = superattr() + 'World'

Actually, it's suboptimally elegant code. Artistic code, to be clear, as 
if you looked at modern art and thought: WTF? Also, it's specific for 
templates only and supports only __add__.


But I think the approach can be extended to a general superclass() if 
you log __getattr__ calls and apply them in __get__ method same way.


I realize this reply is not an immediate help and probably won't help, 
but there's always a way out.


Axy.

Here's the code:


class  superattr:
     '''
This is a descriptor that allows extending attributes in a simple and 
elegant way:


my_attr = superattr() + some_addition_to_my_attr
'''
     def  __init__(self):
     self.additions  =  []

     def  __set_name__(self,  owner,  name):
     print('__set_name__',  name)
     self.attr_name  =  name

     def  __get__(self,  obj,  objtype=None):
     for  cls  in  obj.__class__.__mro__[1:]:
     try:
     value  =  getattr(cls,  self.attr_name)
     except  AttributeError:
     continue
     for  a  in  self.additions:
     value  =  value  +  a
     return  value
     raise  AttributeError(self.attr_name)

     def  __add__(self,  other):
     print('__add__:',  other)
     self.additions.append(other)
     return  self Full article: 
https://declassed.art/en/blog/2022/07/02/a-note-on-multiple-inheritance-in-python


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

Re: Logging

[Chris Angelico]

On Sun, 20 Nov 2022 at 12:27, Cameron Simpson  wrote:
>
> On 19Nov2022 18:26, Thomas Passin  wrote:
> >>The alternative is to just replace every calling function which uses
> >>my_ugly_debug() to directly call a logging.whatever() call.
> >
> >Maybe a place for a decorator...
>
> Indeed, though I don't think the OP is up to decorators yet.
>
> But really, is there any problem which cannot be solved with a
> decorator? I've even got a @decorator decorator for my decorators.
>

Do you have a @toomanydecorators decorator to reduce the number of
decorators you need to decorate your decorators?

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

Re: Logging

[Cameron Simpson]

On 19Nov2022 18:26, Thomas Passin  wrote:
The alternative is to just replace every calling function which uses 
my_ugly_debug() to directly call a logging.whatever() call.


Maybe a place for a decorator...


Indeed, though I don't think the OP is up to decorators yet.

But really, is there any problem which cannot be solved with a 
decorator? I've even got a @decorator decorator for my decorators.


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

Re: Logging

[Thomas Passin]

On 11/19/2022 5:27 PM, Cameron Simpson wrote:

On 19Nov2022 11:08, Stefan Ram  wrote:

 writes:

You are expected to implement logging feature to an existing
code which uses the function below. [...]
You are not allowed to make changes in my_ugly_debug, so find another 
way.


 If found a solution that is even more ugly than your
 function. I was just about to post it here, but then
 remembered about the "no homework" rule. Bummer!


I suspect that the OP is just being asked to modify existing code which 
calls my_ugly_debug to use more conventional logging calls.


Baran, in addition to the various info(), warning() etc logging calls 
there is a log() logging call which accepts a log level (the warning() 
etc calls basicly call this with their own logging level).


I would be inclined to write a my_better_debug(s,level=0) function which 
took those existing levels (0,1,2) and mapped them to the official 
logging levels logging.INFO, logging.WARNING etc, and then called 
logging.log() with the official level.


Then adjust the calling code to call your new function.

The alternative is to just replace every calling function which uses 
my_ugly_debug() to directly call a logging.whatever() call.


Maybe a place for a decorator...



Cheers,
Cameron Simpson 


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

Re: Passing information between modules

[Cameron Simpson]

On 18Nov2022 10:53, Stefan Ram  wrote:

 Can I use "sys.argv" to pass information between modules
 as follows? [...]


Stefan, it looks like most of the replies take the form: yes you can do 
that but it is probably a bad idea.


Could you outline the larger situation where  you want to do this? Often 
this kind of response ("yes but don't!") can be a clue that you're 
chasing the wrong (sorry, "suboptimal/poor") solution to a problem which 
can be solved in another way.


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

Re: Logging

[Cameron Simpson]

On 19Nov2022 11:08, Stefan Ram  wrote:

 writes:

You are expected to implement logging feature to an existing
code which uses the function below. [...]
You are not allowed to make changes in my_ugly_debug, so find another 
way.


 If found a solution that is even more ugly than your
 function. I was just about to post it here, but then
 remembered about the "no homework" rule. Bummer!


I suspect that the OP is just being asked to modify existing code which 
calls my_ugly_debug to use more conventional logging calls.


Baran, in addition to the various info(), warning() etc logging calls 
there is a log() logging call which accepts a log level (the warning() 
etc calls basicly call this with their own logging level).


I would be inclined to write a my_better_debug(s,level=0) function which 
took those existing levels (0,1,2) and mapped them to the official 
logging levels logging.INFO, logging.WARNING etc, and then called 
logging.log() with the official level.


Then adjust the calling code to call your new function.

The alternative is to just replace every calling function which uses 
my_ugly_debug() to directly call a logging.whatever() call.


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

Re: Passing information between modules

[Thomas Passin]

On 11/19/2022 3:46 PM, Michael F. Stemper wrote:

On 18/11/2022 04.53, Stefan Ram wrote:

   Can I use "sys.argv" to pass information between modules
   as follows?

   in module A:

import sys
sys.argv.append( "Hi there!" )

   in module B:

import sys
message = sys.argv[ -1 ]


I just tried and it appears that one can append to sys.argv. However,
it seems like an incredibly bad idea.


For that matter, you can just directly add attributes to the sys module, 
no need to use sys.argv:


>>> import sys
>>> sys._extra = 'spam'   # Not an exception
>>> print(sys._extra)
spam

Probably not the best idea, though.  Better to use some module that you 
control directly.



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

Re: Passing information between modules

[Thomas Passin]

On 11/19/2022 4:28 PM, Thomas Passin wrote:

On 11/19/2022 3:46 PM, Michael F. Stemper wrote:

On 18/11/2022 04.53, Stefan Ram wrote:

   Can I use "sys.argv" to pass information between modules
   as follows?

   in module A:

import sys
sys.argv.append( "Hi there!" )

   in module B:

import sys
message = sys.argv[ -1 ]


I just tried and it appears that one can append to sys.argv. However,
it seems like an incredibly bad idea.


For that matter, you can just directly add attributes to the sys module, 
no need to use sys.argv:


 >>> import sys
 >>> sys._extra = 'spam'   # Not an exception
 >>> print(sys._extra)
spam

Probably not the best idea, though.  Better to use some module that you 
control directly.


This could be one of those things of which Raymond Chen (The Old New 
Thing) asks "what if everyone did this?".  Imagine if every 
(non-standard-library) module misused sys or sys.argv like this.  The 
result could be chaotic.


Best to put all your own stuff into modules that you yourself control.

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

Re: Passing information between modules

[Michael F. Stemper]

On 18/11/2022 04.53, Stefan Ram wrote:

   Can I use "sys.argv" to pass information between modules
   as follows?

   in module A:

import sys
sys.argv.append( "Hi there!" )

   in module B:

import sys
message = sys.argv[ -1 ]


I just tried and it appears that one can append to sys.argv. However,
it seems like an incredibly bad idea.

--
Michael F. Stemper
The name of the story is "A Sound of Thunder".
It was written by Ray Bradbury. You're welcome.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Passing information between modules

[dn]

On 18/11/2022 23.53, Stefan Ram wrote:

   Can I use "sys.argv" to pass information between modules
   as follows?

   in module A:

import sys
sys.argv.append( "Hi there!" )

   in module B:

import sys
message = sys.argv[ -1 ]

   . "sys.argv" is said to be a list by the standard
   documentation, so it should be guaranteed to be
   appendable as lists are appendable.

   Moreover, in my own program, after its startup, third parties
   do not inspect "sys.argv". So by appending something to it
   (or modifying it) I do not tamper with information that might
   be misinterpreted by any third party outside of my own code.

   Another hack might be:

   in module A

import builtins
builtins.message = "Hi there!"

   in module B

import builtins
message = builtins.message

   But I'm not sure whether modules (such as "builtins" here)
   are guaranteed to be modifyable and visible by the language
   reference in this way though



The re-use of built-in features is risky, if only because of the remote 
possibility that a future version of Python will add something that 
clashes. That's why Python makes such good (and careful) use of namespaces!


In some respects we have the (OP) problem because Python does not have 
"interfaces" as a formal component of the language. So, we often 
get-away with taking an easier course - but in doing-so, may forget that 
they serve specific purposes.



There is a general idea that globals are harmful, a code-smell, etc; and 
therefore something to be avoided. However, the global namespace is a 
(built-in!) feature of Python, so why not use it?


The problem comes when we try to re-use module A or B in some other 
application. It may not be relatively-obvious that some global, eg 
config, must be previously-defined and made-available. If you're 
prepared to accept that risk - and presumably combat the criticism by 
carefully (and prominently) documenting it, just as with any other 
docstring, where's the problem? (caveat emptor!)



Considering the use-case, it is unlikely to be as trivial as the 
example-given (OP). A classic example would be set of credentials to 
access an RDBMS and specific table(s).


A 'standard' solution is to collect all such configuration-data at the 
start of the application, into an object (or other data-structure) - I 
usually call it "env" (an instantiation of "Environment").


Thereafter, when needing such data within a module, calling the 
particular function/class/method by name (moduleNM.function(...) ), and 
passing only that section of the env[ironment] required. Such achieved 
by passing some sub-structure of env, or by passing a retrieval/get method.
(a module handling GUI, for example, has no business looking at 
RDBMS-creds - which it would be able to do if the whole env was passed!)



but...

the module's code will expect its data in a particular form (an 
interface!), which must be documented and understood by both the 
provider and consumer (people and software)


- which sounds like the same 'solution' to the 'globals problem'...

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

Logging

[Baran Gökçekli]

How can I solve this question?

There is a module called ‘logging’ to
employ logging facility in Python.

import logging

logging. info('Just a normal message' )

Logging.warning('Not fatal but still noted')

logging.error('There is something wrong')

You are expected to implement logging
feature to an existing code which uses the
function below.

def my_ugly_debug(s, level=0):

pre_text = [ "INFO",
"WARNING",
"ERROR"
  ]

print(f"{pre_text[level]}: {s}")
You are not allowed to make changes in my_ugly_debug, so find another way.

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

Re: Help Merging Of Separate Python Codes

[dn]

On 20/11/2022 02.20, maria python wrote:
Hello, I have these two python codes that work well separately and I 
want to combine them, but I am not sure how to do it. Also after that, I 
want to print the result in txt cvs or another file format. Do you have 
a code for that? Thank you.



Have you tried joining them together, one after the other?

Have you looked at the Python docs?
eg https://docs.python.org/3/library/csv.html

Do you need the help of a professional to write code for you?

If you are learning Python, perhaps the Tutor list will be a more 
appropriate for you...


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

[Python-announce] structlog 22.2.0

[Hynek Schlawack]

I’m happy to announce a new release of structlog!

With more than 4 million downloads per month, structlog is the best solution 
for production-ready structured logging in Python. It doesn’t just allow you to 
log key-value pairs in a structured manner, it also makes it EASIER and FASTER. 
Check out  if you’re intrigued 
but not convinced!

---

This is another (too) big release, but before I go into new features, allow me 
to beg you to check out structlog's documentation: .

I've spent easily half of the time on bringing is up to date, restructuring, 
and adding usage recipes. Not new in this release, but did you know that the 
standard library chapter has flowcharts that give you as visual explanations of 
how the various methods work? This is usually the biggest sticking point when 
starting to use structlog.

Feature-wise the big thing is that structlog's internal (and extremely fast) 
loggers (the one created using structlog.make_filtering_bound_logger() got two 
new features that people have asked for forever:

1.  String interpolation: log.info("hello %s!", "world") works now!
2.  Async! Each logging method has an async version: await log.ainfo("hello 
%s!", "world") is the same thing as above, but async.

Special Thanks

This release would not be possible without my generous sponsors! Thank you to 
all of you making sustainable maintenance possible! If you would like to join 
them, go to https://github.com/sponsors/hynek and check out the sweet perks!

Above and Beyond

Variomedia AG (@variomedia), Tidelift (@tidelift), Sentry (@getsentry), 
HiredScore (@HiredScore), FilePreviews (@filepreviews), and Daniel Fortunov 
(@asqui).

Maintenance Sustainers

@rzijp, Adam Hill (@adamghill), Dan Groshev (@si14), Tamir Bahar (@tmr232), Adi 
Roiban (@adiroiban), Magnus Watn (@magnuswatn), David Cramer (@dcramer), Moving 
Content AG (@moving-content), Stein Magnus Jodal (@jodal), Iwan Aucamp 
(@aucampia), ProteinQure (@ProteinQure), Jesse Snyder (@jessesnyder), Rivo Laks 
(@rivol), Thomas Ballinger (@thomasballinger), @medecau, Ionel Cristian Mărieș 
(@ionelmc), The Westervelt Company (@westerveltco), Philippe Galvan 
(@PhilippeGalvan), Birk Jernström (@birkjernstrom), Jannis Leidel (@jezdez), 
Tim Schilling (@tim-schilling), Chris Withers (@cjw296), and Christopher Dignam 
(@chdsbd).

Not to forget 2 more amazing humans who chose to be generous but anonymous!

Full Changelog

Deprecated

-   Accessing package metadata as attributes on the structlog module is 
deprecated (e.g. structlog.__version__). Please use importlib.metadata instead 
(for Python 3.7: the importlib-metadata PyPI package).
-   The structlog.types module is now deprecated in favor of the 
structlog.typing module. It seems like the Python typing community is settling 
on this name.

Added

-   FilteringBoundLogger (used by default) now allows for string interpolation 
using positional arguments:

>>> log.info("Hello %s! The answer is %d.", "World", 42, x=1)
2022-10-07 10:04.31 [info ] Hello World! The answer is 42. x=1

#454

-   FilteringBoundLogger now also has support for asyncio-based logging. 
Instead of a wrapper class like structlog.stdlib.AsyncBoundLogger, async 
equivalents have been added for all logging methods. So instead of 
log.info("hello") you can also write await log.ainfo("hello") in async 
functions and methods.

This seems like the better approach and if it's liked by the community, 
structlog.stdlib.BoundLogger will get those methods too. #457

Changed

-   The documentation has been heavily overhauled. Have a look if you haven't 
lately! Especially the graphs in the standard library chapter have proven 
valuable to many.
-   The build backend has been switched to Hatch.

Fixed

-   The timestamps in the default configuration now use the correct separator 
(:) for seconds.

___
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