Re: [Twisted-Python] treq POST abborting with: err: ('Could not adapt', '{"....", "..."} )

[Glyph Lefkowitz]

Done.
-g

> On Jan 11, 2017, at 10:05 PM, Tom Most  wrote:
> 
> Sure, I'd be happy to help (but won't get to it until the weekend). Username 
> is twm.
> 
> Thanks,
> Tom
> On 01/11/2017 04:44 PM, Glyph Lefkowitz wrote:
>> 
>>> On Jan 10, 2017, at 6:43 PM, Tom Most < 
>>> tomm...@gmail.com > 
>>> wrote:
>>> 
>>> On 01/08/2017 06:49 PM, Glyph Lefkowitz wrote:
 
> On Jan 6, 2017, at 11:03 AM, steven meiers  > wrote:
> 
> hi,
> 
> 
> sending a simple post request with a body (cookies) results in a error
> here.
> 
> im using python 3.x with the latest twisted and treq installed via pip
> in a virtualenv.
 
 Something that we discussed on IRC but did not come up in the mailing list 
 thread may be the one issue that *should* be fixed in treq:
 
 Because of this issue, this example -  
 http://treq.readthedocs.io/en/latest/#post
   - which the OP was 
 following, doesn't work on Python 3.
 
 We should fix the docs so that it does.
>>> 
>>> I submitted a PR to fix this a while ago:  
>>> https://github.com/twisted/treq/pull/152
>>>  
>>> 
>>> Also, the docs on RTD are still out of date. Who owns them? I'd be happy to 
>>> help.
>> 
>> Thanks, hopefully the next time my periodic review comes around I'll catch 
>> that one.
>> 
>> Looks like I own the docs.  Builds are apparently failing - should I add you 
>> to the project?
>> 
>> -glyph
>> 
>> 
>> 
>> ___
>> Twisted-Python mailing list
>> Twisted-Python@twistedmatrix.com 
>> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python 
>> 
> 
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Twisted 16.7.0rc2 Release Candidate Announcement

[Amber "Hawkie" Brown]

Happy new year!

Twisted 16.7.0rc2 is out, with a bugfix for a problem scrapy ran into. Sorry 
for the delay in 16.7 final, we've had a few regression reports, and we've made 
sure to follow them all up and get to the bottom of them before we did the 
release!

You can get the tarball and the NEWS file at 
https://twistedmatrix.com/Releases/rc/16.7.0rc2/ 
 , or you can try it out from 
PyPI:

python -m pip install Twisted==16.7.0rc2

Please test it, and let me know how your applications fare, good or bad! It 
will release this weekend if nothing is reported.

Regards,
Amber Brown___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Testing Strategies (was Re: Streaming Requests)

[Jean-Paul Calderone]

On Wed, Jan 11, 2017 at 11:41 PM, Glyph Lefkowitz 
wrote:

>
> On Jan 9, 2017, at 4:13 AM, Jean-Paul Calderone 
> wrote:
>
> On Mon, Jan 9, 2017 at 4:52 AM, Glyph Lefkowitz 
> wrote:
>
>> On a related note, 'proto_helpers' is in a super awkward place.
>>  'twisted.testing', anyone? :)
>>
>
> Yes.  I almost suggested this about a week ago when I was preparing to
> contribute some testing code but then realized I couldn't contribute the
> code after all. :(
>
>
> Well, now it's just a matter of time :).
>
>
Some further thoughts on this... What I've actually been doing elsewhere (
*mostly*) is to put the testing implementations quite near the real
implementations.  For example, I recently introduced
`workproject.subscription_manager.{network_client,memory_client}`.  But
contrary to this, in txAWS I'm following the pre-existing pattern which is
more like `txaws.service.AWSServiceRegion.get_ec2_client` &
`txaws.testing.service.FakeAWSServiceRegion.get_ec2_client`.

Which I prefer, I'm not really sure yet.  Role-named modules are easy to
recognize.  On the other hand, testing code next to implementation code is
easier to stumble across and you don't *have* to recognize a separate
testing module to find it.  Also, role-named modules tend to pile up and
get in each other's way (start working with `twisted.testing`,
`txaws.testing`, etc and things start to get confusing quickly).

Additionally, a related idea is that often the testing implementation might
actually serve as a good starting place for the real implementation.  I
think the code in txAWS is a good example of this (ie, the real and fake
implementations duplicate a lot of logic with some pointless divergences).
In the olden days I would have said "the testing implementation is often a
good *base class* for the real implementation".  But now I'll mumble
something about composition.  Put another way:

   - Clock should be the real implementation of all of the time-source
   independent logic of IReactorTime
   - FakeAWSServiceRegion should be the real implementation of the "client
   factory" logic (get_XXX_client) of AWSServiceRegion

and so on.

Perhaps this also speaks to the idea you mentioned that there should be a
stack of thin abstractions but I snipped that content already so I'll try
responding to that separately, later.

Jean-Paul
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] "twistd" in Twisted 16.4.0 can't import modules/packages from current working directory

[Jean-Paul Calderone]

Note there is still some confusion over this matter.  See <
http://twistedmatrix.com/trac/ticket/8972>, <
http://twistedmatrix.com/trac/ticket/8978>, and <
https://github.com/twisted/twisted/pull/672>.

Jean-Paul

On Tue, Jan 3, 2017 at 3:24 PM, Jean-Paul Calderone <
exar...@twistedmatrix.com> wrote:

> On Tue, Jan 3, 2017 at 3:22 PM, Amber "Hawkie" Brown <
> hawk...@atleastfornow.net> wrote:
>
>>
>>
>> We have, in the past, fixed up historic NEWS files in later releases
>> (e.g. the one which removed 2.6 support). We could always roll these
>> changes into a post1, but, that seems like a lot of effort. Maybe we could
>> put errata on the blog?
>>
>>
> With a link to the blog post in the NEWS file?  Cold checking blog was
> below "read git history and try to correlate with the issue tracker" on my
> list of how to track down this change.
>
> Jean-Paul
>
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Testing Strategies (was Re: Streaming Requests)

[Glyph Lefkowitz]

> On Jan 12, 2017, at 4:24 AM, Jean-Paul Calderone  
> wrote:
> 
> On Wed, Jan 11, 2017 at 11:41 PM, Glyph Lefkowitz  > wrote:
> 
>> On Jan 9, 2017, at 4:13 AM, Jean-Paul Calderone > > wrote:
>> 
>> On Mon, Jan 9, 2017 at 4:52 AM, Glyph Lefkowitz > > wrote:
>> On a related note, 'proto_helpers' is in a super awkward place.  
>> 'twisted.testing', anyone? :)
>> 
>> Yes.  I almost suggested this about a week ago when I was preparing to 
>> contribute some testing code but then realized I couldn't contribute the 
>> code after all. :(
> 
> Well, now it's just a matter of time :).
> 
> Some further thoughts on this... What I've actually been doing elsewhere 
> (mostly) is to put the testing implementations quite near the real 
> implementations.  For example, I recently introduced 
> `workproject.subscription_manager.{network_client,memory_client}`.  But 
> contrary to this, in txAWS I'm following the pre-existing pattern which is 
> more like `txaws.service.AWSServiceRegion.get_ec2_client` & 
> `txaws.testing.service.FakeAWSServiceRegion.get_ec2_client`.

"Memory" implementations are definitely a step up the value hierarchy from 
"fake" implementations.

I guess maybe both of these patterns make sense for certain things.  It makes 
sense to put a memory implementation next to the real one (c.f. SQLite), but it 
doesn't make as much sense to put a testing implementation there.  I would make 
this distinction by saying a "testing" implementation is one which has 
assertion method helpers, simulated I/O triggers, and similar.

> Which I prefer, I'm not really sure yet.  Role-named modules are easy to 
> recognize.  On the other hand, testing code next to implementation code is 
> easier to stumble across and you don't have to recognize a separate testing 
> module to find it.  Also, role-named modules tend to pile up and get in each 
> other's way (start working with `twisted.testing`, `txaws.testing`, etc and 
> things start to get confusing quickly).

Yeah, and I guess it'll actually be `twisted.internet.testing`, 
`twisted.python.testing`, `twisted.web.testing` etc.  Which we explicitly 
rejected with `interfaces` because it got too confusing; the existence of 
multiple `endpoints` modules has been mildly irritating while working on 
HostnameEndpoint for the last couple of days.

> Additionally, a related idea is that often the testing implementation might 
> actually serve as a good starting place for the real implementation.  I think 
> the code in txAWS is a good example of this (ie, the real and fake 
> implementations duplicate a lot of logic with some pointless divergences).  
> In the olden days I would have said "the testing implementation is often a 
> good base class for the real implementation".  But now I'll mumble something 
> about composition.

Yeah, I think this is the broader point, actually - the best possible "fake" 
implementation is a completely real implementation where the lower level it's 
composing against is fake.

> Put another way:
> Clock should be the real implementation of all of the time-source independent 
> logic of IReactorTime
One minor tweak: Clock itself should be split into two objects, one of which 
has just 'advance' and one of which has IReactorTime 
>.
  Possibly three objects, since it gets its `seconds` from somewhere else?
> FakeAWSServiceRegion should be the real implementation of the "client 
> factory" logic (get_XXX_client) of AWSServiceRegion 
> and so on.

Yes, definitely.

> Perhaps this also speaks to the idea you mentioned that there should be a 
> stack of thin abstractions but I snipped that content already so I'll try 
> responding to that separately, later.


Ideally, the only "fake" implementation we should need is StringTransport and 
Clock; the abstractions in the middle would be wiring together the layers in a 
way that's convenient for test clients to access.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] "twistd" in Twisted 16.4.0 can't import modules/packages from current working directory

[Glyph Lefkowitz]

Thanks for highlighting those.  I've put the link in the other direction as 
well.

> On Jan 12, 2017, at 3:42 PM, Jean-Paul Calderone  
> wrote:
> 
> Note there is still some confusion over this matter.  See 
>  >, 
>  >, and 
>  >.
> 
> Jean-Paul
> 
> On Tue, Jan 3, 2017 at 3:24 PM, Jean-Paul Calderone 
> mailto:exar...@twistedmatrix.com>> wrote:
> On Tue, Jan 3, 2017 at 3:22 PM, Amber "Hawkie" Brown 
> mailto:hawk...@atleastfornow.net>> wrote:
> 
> 
> We have, in the past, fixed up historic NEWS files in later releases (e.g. 
> the one which removed 2.6 support). We could always roll these changes into a 
> post1, but, that seems like a lot of effort. Maybe we could put errata on the 
> blog?
> 
> 
> With a link to the blog post in the NEWS file?  Cold checking blog was below 
> "read git history and try to correlate with the issue tracker" on my list of 
> how to track down this change.
> 
> Jean-Paul
> 
> 
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python