RE: super().__init__() and bytes

[Anders Munch via Python-list]

Roel Schroeven  wrote:
> As a follow-up, it looks like this behavior is because bytes and int are 
> immutable.

Yes.

> But that doesn't tell me why using super().__init__() 
> doesn't work for immutable classes.

bytes.__init__ does work, but it's just an inherited object.__init__, which 
does nothing, and takes no parameters.
 __init__ cannot change the value of the bytes object; the value is set by 
bytes.__new__ and cannot change after that.

Best not to define an __init__ method at all, just use __new__.

Something like:

class BytesSubclass(bytes):
def __new__(cls, whatever, arguments, you, like):
bytesvalue = compute(whatever, arguments, you, like)
ob = bytes.__new__(cls, bytesvalue)
ob.some_other_att = compute_something_else(whatever, arguments, you, 
like)
return ob

regards, 
Anders

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

Re: super().__init__() and bytes

[Roel Schroeven via Python-list]

Op 3/12/2024 om 10:41 schreef Roel Schroeven via Python-list:

[...]
When I try the same with bytes as base class though, that doesn't work 
(at least in the Python version I'm using, which is CPython 3.11.2 
64-bit on Windows 10):


class MyBytes(bytes):
    def __init__(self, data):
    super().__init__(data)
print(MyBytes(b'abcdefghijlkmn'))

This results in an exception:

Traceback (most recent call last):
  File "test_mybytes.py", line 4, in 
    print(MyBytes(b'abcdefghijlkmn'))
  ^^
  File "test_mybytes.py", line 3, in __init__
    super().__init__(data)
TypeError: object.__init__() takes exactly one argument (the instance 
to initialize)


I'm passing two arguments (data and the implicit self), and apparently 
that's one too many. Let's try without arguments (i.e. only the 
implicit self):


class MyBytes(bytes):
    def __init__(self, data):
    super().__init__()
print(MyBytes(b'abcdefghijlkmn'))

Now it works, and prints b'abcdefghijlkmn'. The same happens with int 
as base class, and presumably a number of other classes.


As a follow-up, it looks like this behavior is because bytes and int are 
immutable. When I try with bytesarray instead of bytes, which works 
largely the same but is mutable, things do work as I expect. There's a 
hint in the documentation of __new__(): "__new__() is intended mainly to 
allow subclasses of immutable types (like int, str, or tuple) to 
customize instance creation". But that doesn't tell me why using 
super().__init__() doesn't work for immutable classes.


The documentation for __init__() says " If a base class has an 
__init__() method, the derived class’s __init__() method, if any, must 
explicitly call it to ensure proper initialization of the base class 
part of the instance; for example: super().__init__([args...])". So does 
that mean that bytes and int not have an __init__() method? Is there a 
link between being immutable and not having __init__()?


--
"Man had always assumed that he was more intelligent than dolphins because
he had achieved so much — the wheel, New York, wars and so on — whilst all
the dolphins had ever done was muck about in the water having a good time.
But conversely, the dolphins had always believed that they were far more
intelligent than man — for precisely the same reasons."
-- Douglas Adams

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

Re: super().__init__() and bytes

[Roel Schroeven via Python-list]

Op 3/12/2024 om 13:55 schreef Anders Munch via Python-list:

Roel Schroeven  wrote:
> As a follow-up, it looks like this behavior is because bytes and int are 
immutable.

Yes.

OK.

> But that doesn't tell me why using super().__init__() 
doesn't work for immutable classes.

bytes.__init__ does work, but it's just an inherited object.__init__, which 
does nothing, and takes no parameters.
  __init__ cannot change the value of the bytes object; the value is set by 
bytes.__new__ and cannot change after that.


I see now why __init__, being a regular method, can't change an object's 
value (or attributes in general) if that object is immutable. I'm not 
sure why I didn't think of that before.


It's not entirely clear to me though how bytes.__new__ *can* set an 
object's value. Isn't __new__ also a regular function? Are these 
immutable classes special cases in the language that can't be recreated 
in the same way with user-defined classes? Not that that's something I 
want to do, and it's also not terribly important to me, but I'm trying 
to better understand what's going on.

Best not to define an __init__ method at all, just use __new__.

Something like:

class BytesSubclass(bytes):
 def __new__(cls, whatever, arguments, you, like):
 bytesvalue = compute(whatever, arguments, you, like)
 ob = bytes.__new__(cls, bytesvalue)
 ob.some_other_att = compute_something_else(whatever, arguments, you, 
like)
 return ob
Thanks, that works perfectly. That's also more important than 
understanding all the nitty-gritty details (I feel a basic understanding 
is important, but not necessarily always all the low-level details).


--
"There is no cause so noble that it will not attract fuggheads."
-- Larry Niven

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

super().__init__() and bytes

[Roel Schroeven via Python-list]

We can use super().__init__() in the __init__() method of a derived 
class to initialize its base class. For example:


import string
class MyTemplate(string.Template):
    def __init__(self, template_string):
    super().__init__(template_string)
print(MyTemplate('Hello ${name}').substitute(name="Pedro"))

This works, and prints "Hello Pedro" as expected. Note that I passed 
template_string in the super().__init__() call, and that is what used to 
initialize the base class. So far nothing special.


When I try the same with bytes as base class though, that doesn't work 
(at least in the Python version I'm using, which is CPython 3.11.2 
64-bit on Windows 10):


class MyBytes(bytes):
    def __init__(self, data):
    super().__init__(data)
print(MyBytes(b'abcdefghijlkmn'))

This results in an exception:

Traceback (most recent call last):
  File "test_mybytes.py", line 4, in 
    print(MyBytes(b'abcdefghijlkmn'))
  ^^
  File "test_mybytes.py", line 3, in __init__
    super().__init__(data)
TypeError: object.__init__() takes exactly one argument (the instance to 
initialize)


I'm passing two arguments (data and the implicit self), and apparently 
that's one too many. Let's try without arguments (i.e. only the implicit 
self):


class MyBytes(bytes):
    def __init__(self, data):
    super().__init__()
print(MyBytes(b'abcdefghijlkmn'))

Now it works, and prints b'abcdefghijlkmn'. The same happens with int as 
base class, and presumably a number of other classes. That behavior is 
beyond my understanding, so I have some questions that might hopefully 
lead to a better understanding:


(1) How does that work? How does my argument end up in the code that 
initializes the instance state?


(2) How can I customize the argument is passed? For example, what if I 
want to do something like (supersimple example) super().__init__(data * 2)?


(3) Why is bytes (and int, ...) different? Is it because it's a builtin? 
Or implemented in C? Or something else?


--
"Man had always assumed that he was more intelligent than dolphins because
he had achieved so much — the wheel, New York, wars and so on — whilst all
the dolphins had ever done was muck about in the water having a good time.
But conversely, the dolphins had always believed that they were far more
intelligent than man — for precisely the same reasons."
-- Douglas Adams

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

Re: Cheetah 3.4.0

[Mohammadreza Saveji via Python-list]

Thanks a lot Oleg
sincerely yours

On Mon, Dec 2, 2024 at 5:27 PM Oleg Broytman via Python-list <
python-list@python.org> wrote:

> Hello!
>
> I'm pleased to announce version 3.4.0, the final release
> of branch 3.4 of CheetahTemplate3.
>
>
> What's new in CheetahTemplate3
> ==
>
> This release spans two topics: adapting to Python 3.13 and
> fixes in import hooks.
>
> Bug fixes:
>
>   - Fixed ``ImportHooks``: it must raise ``ModuleNotFoundError``
> instead of ``ImportError``.
>
>   - Fixed absolute import in ``ImportHooks`` under Python 3.
>
>   - Use ``cache_from_source`` in ``ImportManager`` to find out
> ``.pyc``/``.pyo`` byte-code files.
>
>   - Fixed unmarshalling ``.pyc``/``.pyo`` byte-code files
> in ``ImportManager``.
>
>   - Fixed ``Template.webInput``: Use ``urllib.parse.parse_qs``
> instead of ``cgi.FieldStorage``; Python 3.13 dropped ``cgi``.
>
>   - Fixed ``_namemapper.c``: Silent an inadvertent ``TypeError`` exception
> in ``PyMapping_HasKeyString`` under Python 3.13+
> caused by ``_namemapper`` looking up a key in a non-dictionary.
>
>   - Fixed ``_namemapper.c``: Silence ``IndexError`` when testing
> ``name[attr]``. Some objects like ``re.MatchObject`` implement both
> attribute access and index access. This confuses ``NameMapper`` because
> it expects ``name[attr]`` to raise ``TypeError`` for objects that don't
> implement mapping protocol.
>
>   - Fixed mapping test in ``NameMapper.py``:
> Python 3.13 brough a new mapping type ``FrameLocalsProxy``.
>
>   - Fixed another ``RecursionError`` in ``ImportHooks`` under PyPy3.
>
> Tests:
>
>   - tox: Run tests under Python 3.13.
>
> CI:
>
>   - CI(GHActions): Switch to ``setup-miniconda``.
>
>   - CI(GHActions): Run tests under Python 3.13.
>
> Build/release:
>
>   - Rename sdist to lowercase; different build tools produce different
> case.
> This is important because stupid PyPI doesn't ignore sdists
> in different cases but also doesn't allow uploading.
> So we use single case, all lower. Also see PEP 625.
>
>
> What is CheetahTemplate3
> 
>
> Cheetah3 is a free and open source (MIT) Python template engine.
> It's a fork of the original CheetahTemplate library.
>
> Python 2.7 or 3.4+ is required.
>
>
> Where is CheetahTemplate3
> =
>
> Site:
> https://cheetahtemplate.org/
>
> Download:
> https://pypi.org/project/CT3/3.4.0
>
> News and changes:
> https://cheetahtemplate.org/news.html
>
> StackOverflow:
> https://stackoverflow.com/questions/tagged/cheetah
>
> Mailing lists:
> https://sourceforge.net/p/cheetahtemplate/mailman/
>
> Development:
> https://github.com/CheetahTemplate3
>
> Developer Guide:
> https://cheetahtemplate.org/dev_guide/
>
>
> Example
> ===
>
> Install::
>
> $ pip install CT3 # (or even "ct3")
>
> Below is a simple example of some Cheetah code, as you can see it's
> practically
> Python. You can import, inherit and define methods just like in a regular
> Python
> module, since that's what your Cheetah templates are compiled to :) ::
>
> #from Cheetah.Template import Template
> #extends Template
>
> #set $people = [{'name' : 'Tom', 'mood' : 'Happy'}, {'name' : 'Dick',
> 'mood' : 'Sad'}, {'name' : 'Harry', 'mood' :
> 'Hairy'}]
>
> How are you feeling?
> 
> #for $person in $people
> 
> $person['name'] is $person['mood']
> 
> #end for
> 
>
> Oleg.
> --
> Oleg Broytmanhttps://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [RELEASE] Python 3.13.1, 3.12.8, 3.11.11, 3.10.16 and 3.9.21 are now available

[Jason Friedman via Python-list]

🙏

On Tue, Dec 3, 2024 at 5:06 PM Thomas Wouters via Python-list <
python-list@python.org> wrote:

> Another big release day! Python 3.13.1 and 3.12.8 were regularly scheduled
> releases, but they do contain a few security fixes. That makes it a nice
> time to release the security-fix-only versions too, so everything is as
> secure as we can make it.
> <
> https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-3131-1
> >Python
> 3.13.1
>
> Python 3.13’s first maintenance release. My child is all growed up now, I
> guess! Almost 400 bugfixes, build improvements and documentation changes
> went in since 3.13.0, making this the very best Python release to date.
> https://www.python.org/downloads/release/python-3131/
> <
> https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-3128-2
> >Python
> 3.12.8
>
> Python 3.12 might be slowly reaching middle age, but still received over
> 250 bugfixes, build improvements and documentation changes since 3.12.7.
> https://www.python.org/downloads/release/python-3128/
> <
> https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-3-3
> >Python
> 3.11.11
>
> I know it’s probably hard to hear, but this is the *second* security-only
> release of Python 3.11. Yes, really! Oh yes, I know, I know, but it’s true!
> Only 11 commits went in since 3.11.10.
> https://www.python.org/downloads/release/python-3/
> <
> https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-31016-4
> >Python
> 3.10.16
>
> Python 3.10 received a total of 14 commits since 3.10.15. Why more than
> 3.11? Because it needed a little bit of extra attention to keep working
> with current GitHub practices, I guess.
> https://www.python.org/downloads/release/python-31016/
> <
> https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-python-3921-5
> >Python
> 3.9.21
>
> Python 3.9 isn’t quite ready for pasture yet, as it’s set to receive
> security fixes for at least another 10 months. Very similarly to 3.10, it
> received 14 commits since 3.9.20.
> https://www.python.org/downloads/release/python-3921/
> <
> https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-stay-safe-and-upgrade-6
> >Stay
> safe and upgrade!
>
> As always, upgrading is highly recommended to all users of affected
> versions.
> <
> https://discuss.python.org/t/python-3-13-1-3-12-8-3-11-11-3-10-16-and-3-9-21-are-now-available/73214/1#p-211771-enjoy-the-new-releases-7
> >Enjoy
> the new releases
>
> Thanks to all of the many volunteers who help make Python Development and
> these releases possible! Please consider supporting our efforts by
> volunteering yourself or through organization contributions to the Python
> Software Foundation.
>
> Regards from your tireless, tireless release team,
> Thomas Wouters
> Ned Deily
> Steve Dower
> Pablo Galindo Salgado
> Łukasz Langa
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: super().__init__() and bytes

[Greg Ewing via Python-list]

On 4/12/24 3:24 am, Roel Schroeven wrote:
It's not entirely clear to me though how bytes.__new__ *can* set an 
object's value. Isn't __new__ also a regular function?


Yes, but the __new__ methods of the builtin immutable objects (int,
str, bytes, etc.) are implemented in C, and so are able to do things
that Python methods cannot.

--
Greg

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

[RELEASE] Python 3.13.1, 3.12.8, 3.11.11, 3.10.16 and 3.9.21 are now available

[Thomas Wouters via Python-list]

Another big release day! Python 3.13.1 and 3.12.8 were regularly scheduled
releases, but they do contain a few security fixes. That makes it a nice
time to release the security-fix-only versions too, so everything is as
secure as we can make it.
Python
3.13.1

Python 3.13’s first maintenance release. My child is all growed up now, I
guess! Almost 400 bugfixes, build improvements and documentation changes
went in since 3.13.0, making this the very best Python release to date.
https://www.python.org/downloads/release/python-3131/
Python
3.12.8

Python 3.12 might be slowly reaching middle age, but still received over
250 bugfixes, build improvements and documentation changes since 3.12.7.
https://www.python.org/downloads/release/python-3128/
Python
3.11.11

I know it’s probably hard to hear, but this is the *second* security-only
release of Python 3.11. Yes, really! Oh yes, I know, I know, but it’s true!
Only 11 commits went in since 3.11.10.
https://www.python.org/downloads/release/python-3/
Python
3.10.16

Python 3.10 received a total of 14 commits since 3.10.15. Why more than
3.11? Because it needed a little bit of extra attention to keep working
with current GitHub practices, I guess.
https://www.python.org/downloads/release/python-31016/
Python
3.9.21

Python 3.9 isn’t quite ready for pasture yet, as it’s set to receive
security fixes for at least another 10 months. Very similarly to 3.10, it
received 14 commits since 3.9.20.
https://www.python.org/downloads/release/python-3921/
Stay
safe and upgrade!

As always, upgrading is highly recommended to all users of affected
versions.
Enjoy
the new releases

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Regards from your tireless, tireless release team,
Thomas Wouters
Ned Deily
Steve Dower
Pablo Galindo Salgado
Łukasz Langa
-- 
https://mail.python.org/mailman/listinfo/python-list