pip 20.3 release (heads-up for potential disruption)
On behalf of the Python Packaging Authority, I am pleased to announce that we have just released pip 20.3, a new version of pip. You can install it by running `python -m pip install --upgrade pip`. This is an important and disruptive release -- we explained why in a blog post last year https://pyfound.blogspot.com/2019/12/moss-czi-support-pip.html . We even made a video about it: https://www.youtube.com/watch?v=B4GQCBBsuNU . Blog post with details: https://pyfound.blogspot.com/2020/11/pip-20-3-new-resolver.html Highlights include: * **DISRUPTION**: Switch to the new dependency resolver by default. Watch out for changes in handling editable installs, constraints files, and more: https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-3-2020 * **DEPRECATION**: Deprecate support for Python 3.5 (to be removed in pip 21.0) * **DEPRECATION**: pip freeze will stop filtering the pip, setuptools, distribute and wheel packages from pip freeze output in a future version. To keep the previous behavior, users should use the new `--exclude` option. * Support for PEP 600: Future ‘manylinux’ Platform Tags for Portable Linux Built Distributions. * Add support for MacOS Big Sur compatibility tags. The new resolver is now *on by default*. It is significantly stricter and more consistent when it receives incompatible instructions, and reduces support for certain kinds of constraints files, so some workarounds and workflows may break. Please see our guide on how to test and migrate, and how to report issues: https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-3-2020 . You can use the deprecated (old) resolver, using the flag `--use-deprecated=legacy-resolver`, until we remove it in the pip 21.0 release in January 2021. In pip 21.0 we will also remove support for Python 2.7. You can find more details (including deprecations and removals) in the changelog https://pip.pypa.io/en/stable/news/ , and you can find thank-yous and instructions on reporting issues at https://pyfound.blogspot.com/2020/11/pip-20-3-new-resolver.html . Thank you, Sumana Harihareswara pip project manager Changeset Consulting https://changeset.nyc -- https://mail.python.org/mailman/listinfo/python-list
Re: Reading binary data with the CSV module
On 2020-11-30 03:59, Jason Friedman wrote:
csv.DictReader appears to be happy with a list of strings representing
the lines.
Try this:
contents = source_file.content()
for row in csv.DictReader(contents.decode('utf-8').splitlines()):
print(row)
Works great, thank you! Question ... will this form potentially use less
memory?
for row in
csv.DictReader(source_file.content().decode('utf-8').splitlines()):
print(row)
Yes, but it won't matter that much unless there's a _lot_ of data.
--
https://mail.python.org/mailman/listinfo/python-list
Best-practice for formatted string literals and localization?
Hi,
formatted string literals are great, but can't be used together with
localization:
_(f"These are {count} stones")
will crash babel ("NameError: name 'count' is not defined". And even it
it would succeed, the *evaluated* string would be passed to "_(…)",
resulting in a not-translated string.
Is there a better solution than
_("These are {count} stones").format(count=count)
("Better" = without passing args or kwargs to `format()`)
--
Regards
Hartmut Goebel
| Hartmut Goebel |h.goe...@crazy-compilers.com|
|www.crazy-compilers.com | compilers which you thought are impossible |
--
https://mail.python.org/mailman/listinfo/python-list
Re: Best-practice for formatted string literals and localization?
On Tue, Dec 1, 2020 at 5:31 AM Hartmut Goebel
wrote:
>
> Hi,
>
> formatted string literals are great, but can't be used together with
> localization:
>
> _(f"These are {count} stones")
>
> will crash babel ("NameError: name 'count' is not defined". And even it
> it would succeed, the *evaluated* string would be passed to "_(…)",
> resulting in a not-translated string.
>
> Is there a better solution than
>
> _("These are {count} stones").format(count=count)
>
> ("Better" = without passing args or kwargs to `format()`)
>
Not really, no. The whole point of f-strings is keeping the template
and the interpolations together, and the whole point of localization
tools is keeping them apart. I'm not sure why you're getting that
NameError, but the more fundamental problem is still there; you
absolutely have to do the localization on the constant string with the
template markers still in it, and only afterwards do the
interpolation, so you're basically left with what you're already
doing.
It might be possible to do something with an import hook that
translates _f"" into _("").format(...) but that would be the
best you'd get.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: A problem with opening a file -- again
On Tue, Dec 1, 2020 at 5:36 AM Dennis Lee Bieber wrote: > Off-hand, since you aren't explicitly using "del lf" it means that > __del__() is being called during the process shutdown. Thing is, there is > no guarantee during shutdown of when things are deleted. There is a faint > possibility that the internal "module" that contains the built-in "open" > could be marked unavailable before your "lf" object is deleted. > ... > HOWEVER! YOU DO STILL HAVE THE PROBLEM THAT __del__() is relying on > features that might not be available if it is invoked as part of process > shutdown! You MUST explicitly "del" the object to have any chance that it > runs properly. > Be aware that "del lf" does NOT guarantee that lf.__del__() will be called. The __del__ method is only called when the object is no longer referenced anywhere, and there are certain situations where it might not be called even then (during interpreter shutdown, for instance; and I think some Pythons don't guarantee that __del__ will be called when breaking a reference loop, but don't quote me on that). You absolutely cannot rely on __del__ for this kind of thing, hence the general consensus that a context manager is the way to do it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Converting images to PDF. Final file has blank pages before and after.
Hello, new to the group, rather new to programming.
I'm writing a program that takes images and converts them into PDF's. It works
after quite a few days of trying, however the final file has a blank page
inserted before and after each page containing the images.
This uses FPDF to do the conversion. I've been up and down trying to figure out
where I'm adding an extra page, so it might be an FPDF issue.
def multi_convert(pdf_Filename, file_path):
if (dir):
file_list = []
print(""), print("")
print("Converting... This may take awhile depending on the number of
images.")
for entry in os.scandir(file_path):
if (entry.path.endswith(".jpg") or entry.path.endswith(".png")) and
entry.is_file():
file_list.append(entry.path)
else:
print("Error: ")
print("Invalid Directory - {}", dir)
cover = Image.open(str(file_list[0]))
width, height = cover.size
pdf = FPDF(unit="pt", format=[width, height])
for page in file_list:
pdf.add_page()
pdf.image(str(page))
pdf.output(file_path + pdf_Filename + ".pdf", "F")
exit()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Converting images to PDF. Final file has blank pages before and after.
On 2020-12-01 01:20, Michael Baca wrote:
Hello, new to the group, rather new to programming.
I'm writing a program that takes images and converts them into PDF's. It works
after quite a few days of trying, however the final file has a blank page
inserted before and after each page containing the images.
This uses FPDF to do the conversion. I've been up and down trying to figure out
where I'm adding an extra page, so it might be an FPDF issue.
def multi_convert(pdf_Filename, file_path):
if (dir):
file_list = []
print(""), print("")
print("Converting... This may take awhile depending on the number of
images.")
for entry in os.scandir(file_path):
if (entry.path.endswith(".jpg") or entry.path.endswith(".png"))
and entry.is_file():
file_list.append(entry.path)
else:
print("Error: ")
print("Invalid Directory - {}", dir)
cover = Image.open(str(file_list[0]))
width, height = cover.size
pdf = FPDF(unit="pt", format=[width, height])
for page in file_list:
pdf.add_page()
pdf.image(str(page))
pdf.output(file_path + pdf_Filename + ".pdf", "F")
exit()
It says in the documentation for the .image method:
"""
x:
Abscissa of the upper-left corner. If not specified or equal to None,
the current abscissa is used (version 1.7.1 and up).
y:
Ordinate of the upper-left corner. If not specified or equal to None,
the current ordinate is used; moreover, a page break is triggered first
if necessary (in case automatic page breaking is enabled) and, after the
call, the current ordinate is moved to the bottom of the image (version
1.7.1 and up).
"""
In other words, you're not specifying where the top-left corner of the
image should go, so it's putting it at the current position, wherever
that is, and it's responding to the positioning by inserting additional
pages.
The solution is to specify the images' positions, and, perhaps, also
their sizes, if necessary.
By the way, why doesn't the function end with "exit()"? That'll make it
exit the Python completely; rarely a good idea.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Converting images to PDF. Final file has blank pages before and after.
On Mon, Nov 30 2020 at 05:20:30 PM, Michael Baca wrote:
> Hello, new to the group, rather new to programming.
>
> I'm writing a program that takes images and converts them into PDF's. It
> works after quite a few days of trying, however the final file has a blank
> page inserted before and after each page containing the images.
>
> This uses FPDF to do the conversion. I've been up and down trying to figure
> out where I'm adding an extra page, so it might be an FPDF issue.
>
> def multi_convert(pdf_Filename, file_path):
> if (dir):
> file_list = []
> print(""), print("")
> print("Converting... This may take awhile depending on the number of
> images.")
>
> for entry in os.scandir(file_path):
> if (entry.path.endswith(".jpg") or entry.path.endswith(".png"))
> and entry.is_file():
> file_list.append(entry.path)
> else:
> print("Error: ")
> print("Invalid Directory - {}", dir)
> cover = Image.open(str(file_list[0]))
> width, height = cover.size
>
> pdf = FPDF(unit="pt", format=[width, height])
>
> for page in file_list:
> pdf.add_page()
I've never used FPDF, but have you considered not doing the add_page
explicitly here? The documentation at
https://pyfpdf.readthedocs.io/en/latest/reference/image/index.html might
be useful; see especially the behaviour specified when the "y" parameter
is not specified, as in this case.
> pdf.image(str(page))
>
> pdf.output(file_path + pdf_Filename + ".pdf", "F")
> exit()
If you're unable to resolve the issue, you should report it to pyfpdf at
https://github.com/reingart/pyfpdf/issues (after checking if this is a
known problem).
--
regards,
kushal
--
https://mail.python.org/mailman/listinfo/python-list
Concatenating a Hash to a String
Hello,
I want to store the hashes of strings in a database and I have
problems generating the sql statements. I generate the hashes using
hashlib and then convert it to base64 and I put the base64
representation in the sql. Here is the code:
#!/usr/bin/env python3.8
import base64
import hashlib
def gen_sql(s):
sha = hashlib.sha256()
# need to encode s as binary, otherwise the next line throws
# TypeError: Unicode-objects must be encoded before hashing
sha.update(b"{s}")
ehash = base64.b64encode(sha.digest())
sql = "insert into HASHES value ('" + ehash + "')"
s = "test"
gen_sql(s)
This code throws
$ ./hashinstr.py
Traceback (most recent call last):
File "./hashinstr.py", line 16, in
gen_sql(s)
File "./hashinstr.py", line 13, in gen_sql
sql = "insert into HASHES value ('" + ehash + "')"
TypeError: can only concatenate str (not "bytes") to str
Any help on how to concatenate ehash to the sql?
Regards
rambius
--
Tangra Mega Rock: http://www.radiotangra.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Concatenating a Hash to a String
On Tue, Dec 1, 2020 at 4:34 PM Ivan "Rambius" Ivanov
wrote:
>
> Hello,
>
> I want to store the hashes of strings in a database and I have
> problems generating the sql statements. I generate the hashes using
> hashlib and then convert it to base64 and I put the base64
> representation in the sql. Here is the code:
>
> sql = "insert into HASHES value ('" + ehash + "')"
>
Don't do this! DO NOT do this! Even if it might happen to work with a
base 64 encoded value, this is a terrible terrible bug just waiting to
happen. Instead, use *parameterized queries* and keep your SQL safe.
Concatenating arbitrary data into an SQL statement is one of the top
ten most common and dangerous flaws in application code. Just don't do
it.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Concatenating a Hash to a String
On Tue, Dec 1, 2020 at 12:39 AM Chris Angelico wrote: > Don't do this! DO NOT do this! Even if it might happen to work with a > base 64 encoded value, this is a terrible terrible bug just waiting to > happen. Instead, use *parameterized queries* and keep your SQL safe. OK. What are parameterized queries? Can you give an example? -- Tangra Mega Rock: http://www.radiotangra.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Concatenating a Hash to a String
On Tue, Dec 1, 2020 at 4:53 PM Ivan "Rambius" Ivanov
wrote:
>
> On Tue, Dec 1, 2020 at 12:39 AM Chris Angelico wrote:
> > Don't do this! DO NOT do this! Even if it might happen to work with a
> > base 64 encoded value, this is a terrible terrible bug just waiting to
> > happen. Instead, use *parameterized queries* and keep your SQL safe.
>
> OK. What are parameterized queries? Can you give an example?
>
I've no idea what database you're connecting to, what library you're
using, or anything, but it would look something like this:
conn.execute("insert into hashes values (?)", [hash])
Look up the documentation for what you're working with. It will have a
way to do this.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
