I want to ask you few questions as
Your latest version of aspose_email_for_python_via_net-25.11-py3-none-manylinux1_x86_64.whl do support for python 3.13 and it is tested for it. right?
Plus i am jumping from 22.12 to 25.11
I have purchased new license too but now the .pst files are blank after download i am not getting why?
can you help?
The publicly available documentation does not contain an explicit statement that Aspose.Email for Python via .NET 25.11 has been tested with or officially supports Python 3.13 [5]. If you need a definitive answer, the most reliable source is the product’s release‑notes or a direct confirmation from the Aspose .Email team.
Regarding the blank .pst files after upgrading from 22.12 to 25.11 (even with a new license), the documentation does not provide a specific cause or known limitation for this behavior [5]. To isolate the issue, consider the following steps:
License license = new License(); license.SetLicense("Aspose.Email.lic");).Aspose.Email.Logging.EnableLogging = true;) to capture any warnings or errors during the download.If the PST remains empty after these checks, it is likely a regression in the 25.11 build. Please provide a minimal reproducible code snippet, the exact license‑application code, and the Python version you are using so we can investigate further.
I have just updated Python from version 3.9 to 3.13, and Aspose.Email
from Aspose.Email_for_Python_via_NET-22.12-py3-none-manylinux1_x86_64.whl
to aspose_email_for_python_via_net-25.11-py3-none-manylinux1_x86_64.whl.
As there were no breaking code changes mentioned in the documentation, I did not find any issues.
Using the same code that worked fine with the old Python and Aspose version, and with correct data in the .pst file, I am now doing everything exactly as before. However, after generating the .pst file, it turns out to be empty.
The public documentation does not contain an explicit statement that Aspose.Email for Python via .NET 25.11 has been tested with or officially supports Python 3.13 [1]. For a definitive answer you would need to check the product’s release‑notes or obtain a direct confirmation from the Aspose .Email team [1].
If a PST file generated with version 25.11 is empty, the most common causes are:
License not applied correctly – the license must be set before any PST operation, e.g.
from aspose.email import License
lic = License()
lic.set_license("Aspose.Email.lic")
Verify that this code runs without errors [1].
Source PST actually empty – open the source PST with a viewer or a minimal Aspose script to confirm it contains items [1].
API changes or required parameters – although no breaking changes were announced, compare the overloads used in 22.12 with those in 25.11 and ensure all required arguments are supplied [1].
Enable logging to capture warnings/errors –
import aspose.email as ae
ae.Logging.enable_logging = True
Review the log for any messages that indicate why items are not being written [1].
Run a minimal reproducible script on a clean environment (e.g., a fresh VM with Python 3.12/3.13 and only the Aspose.Email wheel installed) to see whether the issue persists [1].
If the PST remains empty after these checks, it is likely a regression in the 25.11 build. Please provide a minimal code snippet, the exact license‑application code, and the Python version you are using so the team can investigate further [1].
How to contact to the aspose.email team?
Hello @Harshvardhanpatil,
Aspose.Email for Python via .NET is compatible with Python 3.5 or newer.
To investigate your issue, we need to reproduce the behavior on our side.
Could you please share a minimal code example that you are using to generate the PST file?
Thank you.
I have identified an important change after upgrading from version 22.12 to 25.7/25.11.
The method 'MapiMessage.from_stream` has been removed.
Could you please suggest the recommended alternative or replacement for this function?
Yes, you are correct, MapiMessage.from_stream has been removed.
This method was deprecated earlier and has now been eliminated.
Please use the MapiMessage.load method instead. It fully replaces from_stream.
If you were previously passing a stream, the same approach applies: load accepts a stream input and behaves equivalently.
Thank you.
Yes, I checked with ‘dir(MapiMessage)’ but didn’t find ‘from_stream’, so I was in doubt that ‘from_stream’ might have been removed completely. Then I checked your documentation again point:
Loading from Stream.
Url : Loading, Viewing and Parsing MSG file|Documentation
There you have used ‘from_stream’, which confused me. But I know I should consider the code as the source of truth, so that’s fine. Thanks.
I’ll check if this works. If it doesn’t, I’ll get back to this thread.
@margarita.samodurova
BodyContentType.PLAIN_TEXT has been removed, and only BodyContentType.HTML and BodyContentType.RTF are available in Aspose.Email for Python via .NET 25.11. Can you help me with an alternative to BodyContentType.PLAIN_TEXT?
BodyContentType.PLAIN_TEXT has not been removed.
We confirmed that it works in Aspose.Email for Python via .NET 25.11, as shown below:
from aspose.email.mapi import MapiMessage, BodyContentType
mapi = MapiMessage("from@domain.com", "to@domain.com", "subject", "body")
mapi.set_body_content("This is the body content", BodyContentType.PLAIN_TEXT)
No alternative is required.
Yes,
But i am not able to see PLAIN_TEXT when i am doing dir(BodyContentType).
print(dir(BodyContentType)) [‘HTML’, ‘RTF’, ‘abs’, ‘add’, ‘and’, ‘bool’, ‘ceil’, ‘class’, ‘contains’, ‘delattr’, ‘dir’, ‘divmod’, ‘doc’, ‘eq’, ‘float’, ‘floor’, ‘floordiv’, ‘format’, ‘ge’, ‘getattribute’, ‘getitem’, ‘getnewargs’, ‘getstate’, ‘gt’, ‘hash’, ‘index’, ‘init’, ‘init_subclass’, ‘int’, ‘invert’, ‘iter’, ‘le’, ‘len’, ‘lshift’, ‘lt’, ‘members’, ‘mod’, ‘module’, ‘mul’, ‘name’, ‘ne’, ‘neg’, ‘new’, ‘or’, ‘pos’, ‘pow’, ‘qualname’, ‘radd’, ‘rand’, ‘rdivmod’, ‘reduce’, ‘reduce_ex’, ‘repr’, ‘rfloordiv’, ‘rlshift’, ‘rmod’, ‘rmul’, ‘ror’, ‘round’, ‘rpow’, ‘rrshift’, ‘rshift’, ‘rsub’, ‘rtruediv’, ‘rxor’, ‘setattr’, ‘sizeof’, ‘str’, ‘sub’, ‘subclasshook’, ‘truediv’, ‘trunc’, ‘xor’, ‘as_integer_ratio’, ‘bit_count’, ‘bit_length’, ‘conjugate’, ‘denominator’, ‘from_bytes’, ‘imag’, ‘is_integer’, ‘numerator’, ‘real’, ‘to_bytes’]
I have added handling so that I call set_body_content only when the format is HTML or RTF. Otherwise, I do not call set_body_content. Will that break functionality? I assumed that by default it will work for plain text. Is this fine?
What you are seeing is a Python interop / enum exposure detail, not an indication that PLAIN_TEXT is removed or unsupported.
In Aspose.Email for Python via .NET, BodyContentType is a .NET enum, and not all enum members are guaranteed to appear in dir(). This is a known and expected behavior when working with .NET enums through Python — dir() is not a reliable way to enumerate enum values.
BodyContentType.PLAIN_TEXT does exist and is supported, even if it does not show up in dir().
If you do not explicitly call set_body_content, the body content may remain unchanged, be empty, or not be set in the format you expect.
The correct and safe approach is to explicitly set the body content, including plain text.
You’re welcome)