Re: Reportlab / platypus bug?
Dennis Lee Bieber ezt írta (időpont: 2022. márc.
14., H 20:03):
> On Mon, 14 Mar 2022 19:17:31 +0100, Les declaimed the
> following:
>
> >Unfortunately, the reportlab-users mailing list is unavailable (I cannot
> >subscribe). There is paid support but since I already have a workaround, I
> >won't pay for this. I think this is a documentation error of the reportlab
> >package. (They do not mention that stories cannot be reused.)
> >
>
>
> https://github.com/eduardocereto/reportlab/blob/master/src/reportlab/platypus/doctemplate.py
> """
> A document is built when a DocumentTemplate is fed a sequence of Flowables.
> The action of the build consumes the flowables in order and places them
> onto frames on pages as space allows. When a frame runs out of space the
> next frame of the page is used. If no frame remains a new page is created.
> A new page can also be created if a page break is forced.
> """
>
> Well, the code does use the term "consumes"
>
> And down near the bottom (line 980 or so; this is a section that
> does
> multiple passes for special cases)
> """
> # work with a copy of the story, since it is consumed
> tempStory = story[:]
> self.build(tempStory, **buildKwds)
> #self.notify('debug',None)
> """
>
Well, the official user guide (
https://www.reportlab.com/docs/reportlab-userguide.pdf ) only uses the word
"consume" in section "5.5 Frames", but it does not imply that a story
cannot be reused for generating multiple documents. It could also mean that
each document builder consumes each Flowable only once. So I still think
that this behaviour is undocumented.
It is very interesting that they use story[:] to make a swallow copy for
multiple passes. It must work in that particular case (e.g. when you build
the same document multiple times), but it surely does not work when you
build different documents using the same story (throws a LayoutError).
--
https://mail.python.org/mailman/listinfo/python-list
Re: Reportlab / platypus bug?
On 14/03/2022 18:17, Les wrote: Unfortunately, the reportlab-users mailing list is unavailable (I cannot subscribe). There is paid support but since I already have a workaround, I won't pay for this. I think this is a documentation error of the reportlab package. (They do not mention that stories cannot be reused.) I think we can say that my original problem is solved, because I have a workaround that always works. Schachner, Joseph ezt írta (időpont: 2022. márc. 14., H 19:09): Hi Les, so far as I know the reportlab-users list is still running it is hosted (nad has been for many years) at https://pairlist2.pair.net/mailman/listinfo/reportlab-users is that the address you used? I see messages in the archives so some people can use it.-- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Reportlab / platypus bug?
Robin Becker ezt írta (időpont: 2022. márc. 15., K, 14:06): > > > Hi Les, so far as I know the reportlab-users list is still running it is > hosted (nad has been for many years) at > > > https://pairlist2.pair.net/mailman/listinfo/reportlab-users > > is that the address you used? I see messages in the archives so some > people can use it.-- > Yes, it is. I tried to subscribe (twice), but never got the confirmation email. Checked in the spam folder too, but it is nowhere to be found. -- https://mail.python.org/mailman/listinfo/python-list
Re: Reportlab / platypus bug?
.. Hi Les, so far as I know the reportlab-users list is still running it is hosted (nad has been for many years) at https://pairlist2.pair.net/mailman/listinfo/reportlab-users is that the address you used? I see messages in the archives so some people can use it.-- Robin Becker as a test I subscribed under my private email address and the list responded pretty quickly; the request confirmation email ended up in spam though. I believe the list is a fairly old version of mailman, but I don't have any access to the server. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Reportlab / platypus bug?
> > > > > as a test I subscribed under my private email address and the list > responded pretty quickly; the request confirmation > email ended up in spam though. I believe the list is a fairly old version > of mailman, but I don't have any access to the > server. > I tried again, and now I got the confirmation e-mail (in Spam). Thank you! > > -- https://mail.python.org/mailman/listinfo/python-list
Re: Reportlab / platypus bug?
On 15/03/2022 13:20, Les wrote: Robin Becker ezt írta (időpont: 2022. márc. 15., K, 14:06): Hi Les, so far as I know the reportlab-users list is still running it is hosted (nad has been for many years) at https://pairlist2.pair.net/mailman/listinfo/reportlab-users is that the address you used? I see messages in the archives so some people can use it.-- Yes, it is. I tried to subscribe (twice), but never got the confirmation email. Checked in the spam folder too, but it is nowhere to be found. Hi again, Les. I just looked at the list using the admin login and find you are already a member nagy...@gmail.com Laszlo Nagy in fact you are number 1 in the N's. Perhaps you could just try sending a test email. -- Robin Becker -- https://mail.python.org/mailman/listinfo/python-list
Re: Best practice for caching hash
On Sat, 12 Mar 2022 at 22:37, <2qdxy4rzwzuui...@potatochowder.com> wrote: > Once hashing an object fails, why would an application try again? I can > see an application using a hashable value in a hashable situation again > and again and again (i.e., taking advantage of the cache), but what's > the use case for *repeatedly* trying to use an unhashable value again > and again and again (i.e., taking advantage of a cached failure)? Honestly? Don't know. Maybe because the object is passed to different functions and all of them independently test the hashability? I'm clutching at straws. -- https://mail.python.org/mailman/listinfo/python-list
Re: Best practice for caching hash
On 12Mar2022 21:45, Marco Sulla wrote: >I have a custom immutable object, and I added a cache for its hash >value. The problem is the object can be composed of mutable or >immutable objects, so the hash can raise TypeError. Is it sensible to compute the hash only from the immutable parts? Bearing in mind that usually you need an equality function as well and it may have the same stability issues. >In this case I currently cache the value -1. The subsequent calls to >__hash__() will check if the value is -1. If so, a TypeError is >immediately raised. This will also make these values behave badly in dicts/sets, as they all hash to the same bucket. The performance of a hash index is pretty dependent on having roughly even distribution of objects amongst the hash slots. >The problem is the first time I get an error with details, for example: > >TypeError: unhashable type: 'list' > >The subsequent times I simply raise a generic error: > >TypeError You could, you know, cache the original exception. That does keep links to the traceback and therefore all the associates stack frames, so that isn't cheap (it is peerfectly fast - just the reference, t just prevents those things from being reclaimed). >Ok, I can improve it by raising, for example, TypeError: not all >values are hashable. But do you think this is acceptable? Now I'm >thinking about it and it seems a little hacky to me. That's a policy issue. "Acceptable" depends on the imagined use cases. Im' just having a read of your intro: https://github.com/Marco-Sulla/python-frozendict/blob/35611f4cd869383678104dc94f82aa636c20eb24/README.md So your objective is that a frozendict can itself be hashable, allowing, say, sets of frozendicts? In that case I would be inclined to never raise TypeError at all. I'd compute the hash entirely from the keys of the dict and compute equality in the normal fashion: identical keys and then equal corresponding values. That removes the requirement that values be immutable and/or hashable. It that workable? Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Best practice for caching hash
On Wed, 16 Mar 2022 at 10:42, Cameron Simpson wrote: > > On 12Mar2022 21:45, Marco Sulla wrote: > >I have a custom immutable object, and I added a cache for its hash > >value. The problem is the object can be composed of mutable or > >immutable objects, so the hash can raise TypeError. > > Is it sensible to compute the hash only from the immutable parts? > Bearing in mind that usually you need an equality function as well and > it may have the same stability issues. My understanding - and I'm sure Marco will correct me if I'm wrong here - is that this behaves like a tuple: if it contains nothing but hashable objects, it is itself hashable, but if it contains anything unhashable, the entire tuple isn't hashable. (Though it's a little confusing; a frozendict has to have nothing but immutable objects, yet it permits them to be unhashable? I know of hashable mutable objects, but can't think of any unhashable immutable objects. And I'm not sure whether a hashable-mutable would be permitted in a frozendict, or whether it'd even know.) As such, any valid hash value will be stable, and "asking for a hash will raise TypeError" is also stable. > >The problem is the first time I get an error with details, for example: > > > >TypeError: unhashable type: 'list' > > > >The subsequent times I simply raise a generic error: > > > >TypeError > > You could, you know, cache the original exception. That does keep links > to the traceback and therefore all the associates stack frames, so that > isn't cheap (it is peerfectly fast - just the reference, t just prevents > those things from being reclaimed). I don't like that idea myself, for that exact reason - it'll keep arbitrary numbers of objects alive. But caching the stringified form would be more reasonable here, and have similar effect. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Reportlab / platypus bug?
On 16/03/22 2:20 am, Les wrote: I tried to subscribe (twice), but never got the confirmation email. Checked in the spam folder too, but it is nowhere to be found. Is there any chance your email provider has some kind of quarantine system separate from your spam folder? The University of Canterbury recently started using a Microsoft thing for all its email, and it thinks a large proportion of messages in the Python mailing lists are Very Dangerous Phishing Emails and helpfully quarantines them for me behind a clunky web interface. :-( -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Best practice for caching hash
On 16Mar2022 10:57, Chris Angelico wrote: >> Is it sensible to compute the hash only from the immutable parts? >> Bearing in mind that usually you need an equality function as well and >> it may have the same stability issues. > >My understanding - and I'm sure Marco will correct me if I'm wrong >here - is that this behaves like a tuple: if it contains nothing but >hashable objects, it is itself hashable, but if it contains anything >unhashable, the entire tuple isn't hashable. A significant difference is that tuples have no keys, unlike a dict. A hash does not have to hash all the internal state, ony the relevant state, and not even all of that. The objective of the hash is twofold to my mind: - that "equal" objects (in the `==` sense) have the same hash, so that they hash to the same backet in dicts and can therefore be found - that hash values are widely distributed, to maximise the evenness of the object distribution in buckets For dicts to work, the former has to hold. The latter has more flexibility. A dict has keys. If the dicts are quite varied (sets of tags for example), it may be effective to just hash the keys. But if the dict keys are similar (labelled CSV-rows-as-dicts, or likewise with database rows) this will go badly because the hashes will all (or maybe mostly) collide. >As such, any valid hash value will be stable, and "asking for a hash >will raise TypeError" is also stable. I would seek to avoid a TypeError for a frozendict, but as you can see above I have not thought of a way to do that which would also have desireable hash characteristics in almost all circumstances. (I think we can accept that almost anything will have pathological cases, but the bad cases in my hash-the-keys notion are not, to my mind, rare.) >> >The problem is the first time I get an error with details, for example: >> >TypeError: unhashable type: 'list' >> >The subsequent times I simply raise a generic error: >> >TypeError >> >> You could, you know, cache the original exception. That does keep links >> to the traceback and therefore all the associates stack frames, so that >> isn't cheap (it is peerfectly fast - just the reference, t just prevents >> those things from being reclaimed). > >I don't like that idea myself, for that exact reason - it'll keep >arbitrary numbers of objects alive. I don't like it either, for that exact reason. That reason is the same reason which has Python 3 exception variables get unset as you leave an `except` clause. I'm sure it irks everyone, but the memory penalty of not doing so is high. >But caching the stringified form >would be more reasonable here, and have similar effect. Mmm, yes. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Best practice for caching hash
On Wed, 16 Mar 2022 at 14:00, Cameron Simpson wrote: > > On 16Mar2022 10:57, Chris Angelico wrote: > >> Is it sensible to compute the hash only from the immutable parts? > >> Bearing in mind that usually you need an equality function as well and > >> it may have the same stability issues. > > > >My understanding - and I'm sure Marco will correct me if I'm wrong > >here - is that this behaves like a tuple: if it contains nothing but > >hashable objects, it is itself hashable, but if it contains anything > >unhashable, the entire tuple isn't hashable. > > A significant difference is that tuples have no keys, unlike a dict. > > A hash does not have to hash all the internal state, ony the relevant > state, and not even all of that. The objective of the hash is twofold to > my mind: > - that "equal" objects (in the `==` sense) have the same hash, so that > they hash to the same backet in dicts and can therefore be found > - that hash values are widely distributed, to maximise the evenness of > the object distribution in buckets > > For dicts to work, the former has to hold. Python only demands the first one. And Python's own integers hash to themselves, which isn't what I'd call "widely distributed", but which works well in practice. > The latter has more flexibility. A dict has keys. If the dicts are quite > varied (sets of tags for example), it may be effective to just hash the > keys. But if the dict keys are similar (labelled CSV-rows-as-dicts, or > likewise with database rows) this will go badly because the hashes will > all (or maybe mostly) collide. The general recommendation is to use all the same data for hashing as you use for equality checking. What's the point of just hashing the keys, if the values also contribute to equality? I'd just keep it simple, and hash both. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
