[Python-Dev] [WARNING] Some users who downloaded the Python 3.5.8 .xz tarball got the wrong version
Due to awkward CDN caching, some users who downloaded the source code tarballs of Python 3.5.8 got a preliminary version instead of the final version. As best as we can tell, this only affects the .xz release; there are no known instances of users downloading an incorrect version of the .tgz file. If you downloaded "Python-3.5.8.tar.xz" during the first twelve hours of its release, you might be affected. It's easy to determine this for yourself. The file size (15,382,140 bytes) and MD5 checksum (4464517ed6044bca4fc78ea9ed086c36) published on the release page have always matched the correct version. Also, the GPG signature file will only report a "Good signature" for the correct .xz file (using "gpg --verify"). What's the difference between the two? The only difference is that the final version also merges a fix for Python issue tracker #38243: https://bugs.python.org/issue38243 The fix adds a call to "html.escape" at a judicious spot, line 896 in Lib/xmlrpc/server.py. The only other changes are one new test, to ensure this new code is working, and an entry in the NEWS file. You can see the complete list of changes here: https://github.com/python/cpython/pull/16516/files What should you do? It's up to you. * If you and your users aren't using the XMLRPC library built in to Python, you don't need to worry about which version of 3.5.8 you downloaded. * If you downloaded the .tgz tarball or the Git repo, you already have the correct version. * If you downloaded the xz file and want to make sure you have the fix, check the MD5 sum, and if it's wrong download a fresh copy (and make sure that one matches the known good MD5 sum!). To smooth over this whole sordid mess, I plan to make a 3.5.9 release in the next day or so. It'll be identical to the 3.5.8 release; its only purpose is to ensure that all users have the same updated source code, including the fix for #38243. Sorry for the mess, everybody, //arry/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OYNQS2BZYABXACBRHBHV4RCEPQU5R6EP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python
On Thu., 31 Oct. 2019, 8:30 am Brett Cannon, wrote: > Barry Warsaw wrote: > > On Oct 30, 2019, at 14:31, Łukasz Langa luk...@langa.pl > > wrote: > > > Yes. This allows for synchronizing the schedule of > > > Python release management with Fedora. They've been historically very > helpful in early > > > finding regressions not only in core Python but also in third-party > libraries, helping > > > moving the community forward. It seems like a bargain to make a slight > adjustment of our > > > schedule to help Fedora help us make 3.9 and beyond better releases. > > > It would be really interesting for the major distros to work together, > > coordinating their archive rebuilds with the new/beta releases. E.g. > Ubuntu might be > > ahead of Fedora, or vice versa, for any particular new Python release. > Rebuilding the > > whole archive with the new version as default always uncovered > interesting issues. It > > seems like we have a great untapped resource to find good signals as to > bugs, breakages, > > regressions, and other problems during the Python beta process. How can > that be leveraged > > better? > > I do ask that if there's going to be a discussion about distros working > together and such that it be split off into its own thread to keep this one > on-topic to be specific about the PEP's acceptance. > I think it also ties into the PEP 608 discussion of explicitly expanding our pre-release testing signals, so I'll take it up in that Discourse thread. Cheers, Nick. > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TGYFZET6RJLAIZUFXU2SXMUNCB3Y4NJD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Cleaning the stable ABI [was Accepting PEP 602 -- Annual Release Cycle for Python]
On Thu., 31 Oct. 2019, 6:14 am Steve Dower, wrote: > > Also, PEP 602 makes no statement about when stable ABI APIs are > "committed", and nor does PEP 384, so should we assume that the stable > ABI becomes fixed at beta 1 (or RC 1)? That is, it is not allowed to > remove or change any stable ABI APIs from beta/RC 1, even if they > weren't in the previous release? Or will we hold it until the final > release and allow breaking the stable ABI during prereleases. This is one of the still open questions. My current thinking is: * add the pre-freeze ABI flag proposed in PEP 605 * as long as that is set, both the full ABI and any stable ABI additions since the last stable release are still mutable * we emit a compile warning if the target stable ABI is set to the in-development pre-freeze one * clear the pre-freeze flag for rc1 That way folks will be able to freely build and publish binaries prior to rc1, as long as they're targeting the full ABI or an older version of the stable ABI. Cheers, Nick. > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7ZWXZLFES57UFVYMKSMQB47SY3NB3XA2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python
Barry Warsaw wrote: > On Oct 30, 2019, at 14:31, Łukasz Langa luk...@langa.pl > wrote: > > Yes. This allows for synchronizing the schedule of > > Python release management with Fedora. They've been historically very > > helpful in early > > finding regressions not only in core Python but also in third-party > > libraries, helping > > moving the community forward. It seems like a bargain to make a slight > > adjustment of our > > schedule to help Fedora help us make 3.9 and beyond better releases. > > It would be really interesting for the major distros to work together, > coordinating their archive rebuilds with the new/beta releases. E.g. Ubuntu > might be > ahead of Fedora, or vice versa, for any particular new Python release. > Rebuilding the > whole archive with the new version as default always uncovered interesting > issues. It > seems like we have a great untapped resource to find good signals as to bugs, > breakages, > regressions, and other problems during the Python beta process. How can that > be leveraged > better? I do ask that if there's going to be a discussion about distros working together and such that it be split off into its own thread to keep this one on-topic to be specific about the PEP's acceptance. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZOEKC4J4JJZKEHIM3J2KVI3OU7S45IM6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python
On Oct 30, 2019, at 14:31, Łukasz Langa wrote: > > Yes. This allows for synchronizing the schedule of Python release management > with Fedora. They've been historically very helpful in early finding > regressions not only in core Python but also in third-party libraries, > helping moving the community forward. It seems like a bargain to make a > slight adjustment of our schedule to help Fedora help us make 3.9 and beyond > better releases. It would be really interesting for the major distros to work together, coordinating their archive rebuilds with the new/beta releases. E.g. Ubuntu might be ahead of Fedora, or vice versa, for any particular new Python release. Rebuilding the whole archive with the new version as default always uncovered interesting issues. It seems like we have a great untapped resource to find good signals as to bugs, breakages, regressions, and other problems during the Python beta process. How can that be leveraged better? -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WBEJVYJIP4K53JCA7ICG5ENZB762W6KK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: small improvement idea for the CSV module
On 29Oct2019 21:37, Oz Tiram wrote: Quite a few tutorials show how to use namedtuple to gain memory saving and speed, over the DictReader. [...] Python's own documentation has got a recipe in the collections modules[1] Hence, I was wondering why not go the extra step and add a new class to the CSV module NamedTupleReader? This class would do a good service for Python's users, especially newcomers who are still not aware of modules like the collections module. Just for some context: It is often suggested that several things which are just documentation examples in modules like collections or itertools get promoted to presupplied functions/classes. It tends to fail. Personally I think at least some of these would be a good thing. (Disclaimer: I am not a core dev.) The tricky bit is the bikeshedding: what nice-but-superfluous features or corner cases should it support? I'd be for such things provided they lent themselve to extension i.e. "here's a basic implementation which is easily subclassable for extra features". The other thing is that there are probably examples of csv->namedtuple scattered throughout pypi, users might just need to find them. I know I've written such a thing for myself: https://pypi.org/project/cs.csvutils/ I entirely agree this would be easier to find and use in the stdlib. And mine is probably overfeatured and underclean for use in the stdlib. Cheers, Cameron Simpson ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TFZOWA6RNPCKHD36I64OKCHXXLU5HXKV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python
> On 30 Oct 2019, at 20:26, Brett Cannon wrote: > > On behalf of the steering council I am happy to announce that as > BDFL-Delegate I am accepting PEP 602 to move us to an annual release schedule > (gated on a planned update; see below). Thank you, I'm excited! Nit: > * 3 months for betas instead of 2 3 months instead of 4. But keep the number of releases, just compressing the timing between them slightly. > * 2 months for RCs instead of 1 Yes. This allows for synchronizing the schedule of Python release management with Fedora. They've been historically very helpful in early finding regressions not only in core Python but also in third-party libraries, helping moving the community forward. It seems like a bargain to make a slight adjustment of our schedule to help Fedora help us make 3.9 and beyond better releases. I'll make the necessary adjustments to PEP 602 first thing in the morning (hi from Poland!). > As part of the shift to a 2 year deprecation time frame I will be restarting > discussions around PEP 387 as BDFL-Delegate so we can have a more clear > deprecation and backwards-compatibility policy as well for those that find an > annual cycle too fast which will be updated to reflect this two year time > frame (head's up, Benjamin ). Looking forward to that! - Ł signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SRCNMKRQFAKIWB7MZ34WB6REYUGVZIVK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python
On Oct 30, 2019, at 12:50, Matthias Klose wrote: > > On 30.10.19 20:26, Brett Cannon wrote: >> This was discussed on https://discuss.python.org > > I appreciate that you are informing the python-dev ML. However this > discussion was never announced on the ML. I assume this is a kind of thing > that makes the ML obsolete and forces everyone into discourse. Doko, as to the substance of PEP 602, does the annual release cadence in October cause problems for Ubuntu? -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KTQFQ5EXVTELHWXJUHN4XL3XUNUKPEIY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Cleaning the stable ABI [was Accepting PEP 602 -- Annual Release Cycle for Python]
Steve Dower wrote: > On 30Oct2019 1226, Brett Cannon wrote: > > > > Now that the stable ABI has been cleaned, extension modules should feel more > > comfortable targeting the stable ABI which should make supporting newer > > versions of Python > > much easier > > > > I'm taking this as an indication that we should finish > https://bugs.python.org/issue23903 to > actually clean the stable ABI and > make it usable on Windows. I would, but then I would have wanted the stable ABI to be clean and work on Windows regardless. :) > Specifically: > > existing APIs that accidentally shipped in the stable ABI have to > remain in the stable ABI if they are currently listed in python3.def > _all_ current stable ABI APIs according to the header files will be > added to python3.def, whether they were intended to be stable or not > (with a grace period of however long it takes us to finish issue23903) > in future, the file will be either auto-generated or validated against > the actual headers, to ensure it doesn't get out of sync again > > Hopefully this won't be as upsetting to people as last time we tried to > fix it, but if anyone still has concerns about the stable ABI not being > properly clean, you need to speak up :) > Also, PEP 602 makes no statement about when stable ABI APIs are > "committed", and nor does PEP 384, so should we assume that the stable > ABI becomes fixed at beta 1 (or RC 1)? That is, it is not allowed to > remove or change any stable ABI APIs from beta/RC 1, even if they > weren't in the previous release? Or will we hold it until the final > release and allow breaking the stable ABI during prereleases. Don't know. That's probably a discussion to have and decide where the results of that discusion should be specified (PEP 384, 387, or 602). ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4DFX5ZQFDBGK2FVFMEKTXIEK5UJWWUBX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python
This PEP was mentioned on python-dev at least at https://mail.python.org/archives/list/python-dev@python.org/message/WQ64ZGBECFDIRO6DS7JN3NALYDJGPAAE/ and https://mail.python.org/archives/list/python-dev@python.org/message/YVSOOFLCBHPIA3HBL4L2BFBJENVHZDJC/. This was also covered by the PEP 596 discussion and https://mail.python.org/archives/list/python-dev@python.org/message/Y4XFD7OW5J4ULITO2SSPAWSZ2L76UGMU/ as PEP 602 was split out of PEP 596 and stated as such in that discussion since the latter PEP did double-duty initially as the 3.9 release schedule and changing the release cadence. I will also say that https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296 received 84 replies from 22 participants and 83 replies from 13 people for PEP 605 at https://discuss.python.org/t/pep-605-a-rolling-feature-release-stream-for-cpython/2418 (the PEP 607 announcements never got replies anywhere from what I can tell) so there was participation by folks. When it comes to PEPs, people seem to have naturally gravitated to announcing PEPs on the appropriate mailing list and then directing people to dicsuss.python.org for discussion (specifically the https://discuss.python.org/c/peps category which is open to the public). If you consider that making MLs obsolete then I guess that's seems to have happened at least when it comes to general PEP discussion. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TAFB4KN2U7ZEALHGK3PLDITM3Z44673B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Cleaning the stable ABI [was Accepting PEP 602 -- Annual Release Cycle for Python]
On 30Oct2019 1226, Brett Cannon wrote: * Now that the stable ABI has been cleaned, extension modules should feel more comfortable targeting the stable ABI which should make supporting newer versions of Python much easier I'm taking this as an indication that we should finish https://bugs.python.org/issue23903 to actually clean the stable ABI and make it usable on Windows. Specifically: * existing APIs that accidentally shipped in the stable ABI have to remain in the stable ABI if they are currently listed in python3.def * _all_ current stable ABI APIs according to the header files will be added to python3.def, whether they were intended to be stable or not (with a grace period of however long it takes us to finish issue23903) * in future, the file will be either auto-generated or validated against the actual headers, to ensure it doesn't get out of sync again Hopefully this won't be as upsetting to people as last time we tried to fix it, but if anyone still has concerns about the stable ABI not being properly clean, you need to speak up :) Also, PEP 602 makes no statement about when stable ABI APIs are "committed", and nor does PEP 384, so should we assume that the stable ABI becomes fixed at beta 1 (or RC 1)? That is, it is not allowed to remove or change any stable ABI APIs from beta/RC 1, even if they weren't in the previous release? Or will we hold it until the final release and allow breaking the stable ABI during prereleases. Cheers, Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RA7SCIRIS5WJ6AZDFLMNJRWSYIDA2Y4L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python
On 30.10.19 20:26, Brett Cannon wrote: This was discussed on https://discuss.python.org I appreciate that you are informing the python-dev ML. However this discussion was never announced on the ML. I assume this is a kind of thing that makes the ML obsolete and forces everyone into discourse. Matthias ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TI6GFVMG7UH7LV4S7LUDL4K5KG5LIZNU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Accepting PEP 602 -- Annual Release Cycle for Python
On behalf of the steering council I am happy to announce that as BDFL-Delegate I am accepting PEP 602 to move us to an annual release schedule (gated on a planned update; see below). The steering council thinks that having a consistent schedule every year when we hit beta, RC, and final it will help the community: * Know when to start testing the beta to provide feedback * Known when the expect the RC so the community can prepare their projects for the final release * Know when the final release will occur to coordinate their own releases (if necessary) when the final release of Python occurs * Allow core developers to more easily plan their work to make sure work lands in the release they are targeting * Make sure that core developers and the community have a shorter amount of time to wait for new features to be released The acceptance is gated on Łukasz updating PEP 602 to reflect a planned shift in scheduling (he's been busy with a release of Black): * 3 months for betas instead of 2 * 2 months for RCs instead of 1 This was discussed on https://discuss.python.org in order to give the community enough time to provide feedback in the betas while having enough time to thoroughly test the RC and to prep for the final release so the delay from Python's final release to any new project releases is minimal. It should also fit into the release schedule of Linux distributions like Fedora better than previously proposed so the distributions can test the RC when they start preparing for their own October releases. If this turns out to be a mistake after we try it out for Python 3.9 we can then discuss going back to longer betas and shorter RCs for the release after that. This will not change when feature development is cut off relative to PyCon US nor the core dev sprints happening just before the final release or the alpha of the next version. To help people who cannot upgrade on an annual cycle, do note that: * PEP 602 now says that deprecations will last two releases which is two years instead of the current 18 months * Now that the stable ABI has been cleaned, extension modules should feel more comfortable targeting the stable ABI which should make supporting newer versions of Python much easier As part of the shift to a 2 year deprecation time frame I will be restarting discussions around PEP 387 as BDFL-Delegate so we can have a more clear deprecation and backwards-compatibility policy as well for those that find an annual cycle too fast which will be updated to reflect this two year time frame (head's up, Benjamin ). Thanks to Łukasz, Nick, and Steve for PEPs 602, 605, and 607 and everyone else who provided feedback on those PEPs! ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KE7OS4PZASZMFTW2FP2MWZU5R4Q2QZKU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: small improvement idea for the CSV module
Hi Serhiy, Thanks! Now, I am feeling confused. On the one hand, it's already been tried 10 years ago. On the other hand, obviously people do wish to have it. I'm going to send a PR In GitHub. Let's see if a new PR with some documentation can be appreciated. Oz On Wed, Oct 30, 2019, 16:25 Serhiy Storchaka wrote: > 29.10.19 22:37, Oz Tiram пише: > > Quite a few tutorials show how to use namedtuple to gain memory saving > > and speed, over the DictReader. > > Python's own documentation has got a recipe in the collections modules[1] > > Hence, I was wondering why not go the extra step and add a new class to > > the CSV module NamedTupleReader? > > This class would do a good service for Python's users, especially > > newcomers who are still not aware of > > modules like the collections module. > > See https://bugs.python.org/issue1818 > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/H6L74TDMPP7TSVVKQS2VMI4ZVZTTSMUW/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KKWZBZMBGID45XKEXRX6WQWBDJDMQASD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: small improvement idea for the CSV module
On 10/30/2019 02:53 AM, Steve Holden wrote: If using a dictionary but still requiring attribute access, techniques such as those used at https://github.com/holdenweb/hw can be used to simply client code. Unless I'm missing something, that doesn't have the memory improvement that namedtuples would. -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2VPT4VHW34N45C5WE7XOATB3TB33W2NS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: small improvement idea for the CSV module
29.10.19 22:37, Oz Tiram пише: Quite a few tutorials show how to use namedtuple to gain memory saving and speed, over the DictReader. Python's own documentation has got a recipe in the collections modules[1] Hence, I was wondering why not go the extra step and add a new class to the CSV module NamedTupleReader? This class would do a good service for Python's users, especially newcomers who are still not aware of modules like the collections module. See https://bugs.python.org/issue1818 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/H6L74TDMPP7TSVVKQS2VMI4ZVZTTSMUW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: small improvement idea for the CSV module
On Wed, Oct 30, 2019, 09:43 Steve Holden wrote: > Since 3.7 it may be that dataclasses offer a cleaner implementation of the > functionality you suggest. > Actually, IMO in this case it would be more useful and fitting to use namedtuples rather than dataclasses, since CSV rows are naturally tuple-like, and it would be compatible with existing code written for the tuple-based interface. > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FTY5I2IEMYLM7PVZ6TPXFJKM6CLLN2I4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: small improvement idea for the CSV module
Hi Steve,
Thanks for your reply. While dataclass provide a cleaner API than DictRow
(you can access `row.id` instead of `row["id"]`).
However, dataclass still use the built in `__dict__` instead of
`__slots__`.
```
>>> @dataclass
... class InventoryItem:
... '''Class for keeping track of an item in inventory.'''
... name: str
... unit_price: float
... quantity_on_hand: int = 0
...
>>> cf = InventoryItem("cornflakes", 0.99, 123)
>>> cf
InventoryItem(name='cornflakes', unit_price=0.99, quantity_on_hand=123)
>>> cf.__dict__
{'name': 'cornflakes', 'unit_price': 0.99, 'quantity_on_hand': 123}
```
This means that the users reading large files won't see the suggested
memory improvements.
On the other hand, I'm willing to implement CSVReader classes for both.
`DataClassCSVReader` does offer the
benefit of row instances being mutable, `NamedTupleCSVReader` can be useful
for people leaning toward functional
programming style, where queries on CSV are only meant to find items or
calculate quantities quickly without actually
modifying the rows.
I would be more than happy to know whether such PR would accept.
Best regards
Oz
On Wed, Oct 30, 2019 at 8:39 AM Steve Holden wrote:
> Since 3.7 it may be that dataclasses offer a cleaner implementation of the
> functionality you suggest. It shouldn't be too difficult to produce code
> that uses dataclasses in 3.7+ but falls back to namedtuples when necessary.
> You may wish to consider such an implementation strategy.
>
> Best wishes,
> Steve Holden
>
>
> On Tue, Oct 29, 2019 at 10:59 PM Oz Tiram wrote:
>
>> Hello Python-devs,
>>
>> The csv module is probably heavily utilized by newcomers to Python, being
>> a very popular data exchange format.
>> Although, there are better tools for processing tabular data like SQLite,
>> or Pandas, I suspect this is still a very popular
>> module.
>> There are many examples floating around how one can read and process CSV
>> with the csv module.
>> Quite a few tutorials show how to use namedtuple to gain memory saving
>> and speed, over the DictReader.
>> Python's own documentation has got a recipe in the collections modules[1]
>> Hence, I was wondering why not go the extra step and add a new class to
>> the CSV module NamedTupleReader?
>> This class would do a good service for Python's users, especially
>> newcomers who are still not aware of
>> modules like the collections module.
>> Would someone be willing to sponsor and review such a PR from me?
>> As a smaller change, we could simply add a link from the CSV module's
>> documentation to the recipe in the collections module.
>> What do you think?
>>
>> Best regards
>> Oz
>>
>> [1]:
>> https://docs.python.org/3/library/collections.html?highlight=namedtuple%20csv#collections.namedtuple
>>
>> ---
>> Imagine there's no countries
>> it isn't hard to do
>> Nothing to kill or die for
>> And no religion too
>> Imagine all the people
>> Living life in peace
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/GRPUTYZOPWTTU532CKZOHCTRSHNFKE2M/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
--
---
Imagine there's no countries
it isn't hard to do
Nothing to kill or die for
And no religion too
Imagine all the people
Living life in peace
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/D4SRFILSFXL226473B7KPQ5XFRJCLHQX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: small improvement idea for the CSV module
If using a dictionary but still requiring attribute access, techniques such
as those used at https://github.com/holdenweb/hw can be used to simply
client code.
Kind regards,
Steve Holden
On Wed, Oct 30, 2019 at 11:15 AM Oz Tiram wrote:
> Hi Steve,
>
> Thanks for your reply. While dataclass provide a cleaner API than DictRow
> (you can access `row.id` instead of `row["id"]`).
> However, dataclass still use the built in `__dict__` instead of
> `__slots__`.
>
> ```
> >>> @dataclass
> ... class InventoryItem:
> ... '''Class for keeping track of an item in inventory.'''
> ... name: str
> ... unit_price: float
> ... quantity_on_hand: int = 0
> ...
>
> >>> cf = InventoryItem("cornflakes", 0.99, 123)
> >>> cf
> InventoryItem(name='cornflakes', unit_price=0.99, quantity_on_hand=123)
> >>> cf.__dict__
> {'name': 'cornflakes', 'unit_price': 0.99, 'quantity_on_hand': 123}
> ```
>
> This means that the users reading large files won't see the suggested
> memory improvements.
>
> On the other hand, I'm willing to implement CSVReader classes for both.
> `DataClassCSVReader` does offer the
> benefit of row instances being mutable, `NamedTupleCSVReader` can be
> useful for people leaning toward functional
> programming style, where queries on CSV are only meant to find items or
> calculate quantities quickly without actually
> modifying the rows.
>
> I would be more than happy to know whether such PR would accept.
>
> Best regards
> Oz
>
>
> On Wed, Oct 30, 2019 at 8:39 AM Steve Holden wrote:
>
>> Since 3.7 it may be that dataclasses offer a cleaner implementation of
>> the functionality you suggest. It shouldn't be too difficult to produce
>> code that uses dataclasses in 3.7+ but falls back to namedtuples when
>> necessary. You may wish to consider such an implementation strategy.
>>
>> Best wishes,
>> Steve Holden
>>
>>
>> On Tue, Oct 29, 2019 at 10:59 PM Oz Tiram wrote:
>>
>>> Hello Python-devs,
>>>
>>> The csv module is probably heavily utilized by newcomers to Python,
>>> being a very popular data exchange format.
>>> Although, there are better tools for processing tabular data like
>>> SQLite, or Pandas, I suspect this is still a very popular
>>> module.
>>> There are many examples floating around how one can read and process CSV
>>> with the csv module.
>>> Quite a few tutorials show how to use namedtuple to gain memory saving
>>> and speed, over the DictReader.
>>> Python's own documentation has got a recipe in the collections modules[1]
>>> Hence, I was wondering why not go the extra step and add a new class to
>>> the CSV module NamedTupleReader?
>>> This class would do a good service for Python's users, especially
>>> newcomers who are still not aware of
>>> modules like the collections module.
>>> Would someone be willing to sponsor and review such a PR from me?
>>> As a smaller change, we could simply add a link from the CSV module's
>>> documentation to the recipe in the collections module.
>>> What do you think?
>>>
>>> Best regards
>>> Oz
>>>
>>> [1]:
>>> https://docs.python.org/3/library/collections.html?highlight=namedtuple%20csv#collections.namedtuple
>>>
>>> ---
>>> Imagine there's no countries
>>> it isn't hard to do
>>> Nothing to kill or die for
>>> And no religion too
>>> Imagine all the people
>>> Living life in peace
>>>
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe send an email to python-dev-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-dev@python.org/message/GRPUTYZOPWTTU532CKZOHCTRSHNFKE2M/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>
> --
>
>
> ---
>
> Imagine there's no countries
> it isn't hard to do
> Nothing to kill or die for
> And no religion too
> Imagine all the people
> Living life in peace
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/PU3IIPTWFEH4AJ3V2QPRKZHAGQOOKM4S/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: small improvement idea for the CSV module
Since 3.7 it may be that dataclasses offer a cleaner implementation of the functionality you suggest. It shouldn't be too difficult to produce code that uses dataclasses in 3.7+ but falls back to namedtuples when necessary. You may wish to consider such an implementation strategy. Best wishes, Steve Holden On Tue, Oct 29, 2019 at 10:59 PM Oz Tiram wrote: > Hello Python-devs, > > The csv module is probably heavily utilized by newcomers to Python, being > a very popular data exchange format. > Although, there are better tools for processing tabular data like SQLite, > or Pandas, I suspect this is still a very popular > module. > There are many examples floating around how one can read and process CSV > with the csv module. > Quite a few tutorials show how to use namedtuple to gain memory saving and > speed, over the DictReader. > Python's own documentation has got a recipe in the collections modules[1] > Hence, I was wondering why not go the extra step and add a new class to > the CSV module NamedTupleReader? > This class would do a good service for Python's users, especially > newcomers who are still not aware of > modules like the collections module. > Would someone be willing to sponsor and review such a PR from me? > As a smaller change, we could simply add a link from the CSV module's > documentation to the recipe in the collections module. > What do you think? > > Best regards > Oz > > [1]: > https://docs.python.org/3/library/collections.html?highlight=namedtuple%20csv#collections.namedtuple > > --- > Imagine there's no countries > it isn't hard to do > Nothing to kill or die for > And no religion too > Imagine all the people > Living life in peace > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/GRPUTYZOPWTTU532CKZOHCTRSHNFKE2M/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HGQG4AW2KBS4Q7QUCNTOTMRF3ZJSTRBM/ Code of Conduct: http://python.org/psf/codeofconduct/
