Re: [Python-Dev] static typing of input arguments in signatures (was: Language Summit notes)

[Łukasz Langa]

On Apr 13, 2014, at 12:48 AM, Stefan Behnel  wrote:

> Stefan Behnel, 12.04.2014 19:11:
> 
> So, what I've learned from seven years of Cython is that static typing in
> signatures is actually less interesting than you might think at first
> sight. It might be ok for documentation purposes, although its verboseness
> makes that also a bit questionable.

You raise a valid point that type hinting a dict instead of a Mapping is
likely to create an overly limiting API. This sort of error is however
quite easy to fix forward.

To counter, we’ve had multiple data points during the summit suggesting
that duck typing is not really that often used in production code. In
other words, after initial prototyping and testing, an API of a callable
gets settled and is later used with a very limited number of types.

Of course, fuzzy terms like “often”, “seldom”, and “limited” suggest
that we don’t have hard data here. That being said, there is a clear
need to improve our ability to lint code, refactor code easier, and
document the contracts better. This has been voiced by various
conference attendees and the consensus is tremendous. Moreover, this
need has been proven by owners of large codebases like Google, Facebook,
and Microsoft by creating optionally typed variants of known dynamic
languages (namely Dart, Hack and TypeScript).

For Python specifically the existence of prototypes like Mypy, obiwan,
or pytypedecl shows that there is growing interest in standardizing this
functionality. Therefore, I'm drafting a PEP for opt-in type hints with
optional checks at runtime and by static analysis. Will post the initial
form in the upcoming days, and then we can go paint that bike shed.

I'm aware that great care here is needed for the outcome to feel
Pythonic and not overwhelming. Don't worry before you get your hands on
the draft, though.

-- 
Best regards,
Łukasz Langa

WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Janzert]

On 4/13/2014 2:36 AM, Stephen J. Turnbull wrote:
[snip]

My claim is that in current circumstances,
core-mentorship would be a more *effective* channel because

  - core-mentorship is *explicitly* for poking Those Who Can Help
(among other requests for help);

  - a surprisingly large (to me, anyway :-) fraction of core committers
and people who may not be "core" but do a lot of mentoring for
central projects like IDLE do hang out there; and

  - when reading core-mentorship their "mentor modes" will be engaged,
whereas on python-dev they will often be mostly interested in a
particular thread.



It saddens me that the core-mentorship list has grown into the primary 
acceptable place to ask these getting into core development questions. 
Any question answered there can never benefit the wider community since 
it is kept a closed list for the specific purpose of keeping its 
archives out of public view.


Janzert

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] flock in Python 3

[Jakub QB Dorňák]

You are right, it should be https://pypi.python.org/pypi/flock

- Original Message -
From: "Benjamin Peterson" 
To: "Jakub QB Dorňák" , "Python Dev" 
Sent: Friday, April 11, 2014 6:38:43 PM
Subject: Re: [Python-Dev] flock in Python 3

On Fri, Apr 11, 2014, at 5:58, Jakub QB Dorňák wrote:
> Hi all,
> 
> writing a threaded application I've been surprised that there is no
> object api for fcntl.flock implementing __enter__() and __exit__()
> methods to be used with 'with' statement.
> I have written one (https://pypi.python.org/pypi), but I wonder whether
> this could get into the Python Standard Library.

That link PyPi link is broken.

I think it would be nicer to have a high-level API for cross-platform
file locking. IIRC, flock can be rather non-portable.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Stephen J. Turnbull]

Janzert writes:
 > On 4/13/2014 2:36 AM, Stephen J. Turnbull wrote:
 > [snip]
 > > My claim is that in current circumstances,
 > > core-mentorship would be a more *effective* channel because
 > >
 > >   - core-mentorship is *explicitly* for poking Those Who Can Help
 > > (among other requests for help);
 > >
 > >   - a surprisingly large (to me, anyway :-) fraction of core committers
 > > and people who may not be "core" but do a lot of mentoring for
 > > central projects like IDLE do hang out there; and
 > >
 > >   - when reading core-mentorship their "mentor modes" will be engaged,
 > > whereas on python-dev they will often be mostly interested in a
 > > particular thread.
 > >
 > 
 > It saddens me that the core-mentorship list has grown into the primary 
 > acceptable place to ask these getting into core development questions. 
 > Any question answered there can never benefit the wider community since 
 > it is kept a closed list

That is false.  The list is open, anybody interested can join the list
and read the archives.

 > for the specific purpose of keeping its archives out of public
 > view.

Nobody said core-mentorship is the primary place for getting into core
development questions.  I said that for requesting review of your
patches, it's probably a better venue than here.

However, I take issue with your implied opinion that a lot of the
discussion on core-mentorship is of general interest.  AFAICS most
questions that are being asked are FAQs and requests for review.  Most
are handled well by the dev guide, and the answers don't belong on
this list because they contain little new content *of general
interest*.

Of course there's some loss of information to the "wider community"
due to the (tiny) cost of subscribing and lack of indexing by search
engines, but the benefit of directing new developers to
core-mentorship is that S/N increases for *both* sets of users (not
just the subscribers to -dev, but the new developers, too).

What bothers me is a *much* larger leak: the issue tracker.  Although
I suppose that technically speaking it's a little easier to access and
indexed by Google, there is surely a lot of implementation and style
advice that just isn't going to be accessible to anybody who doesn't
already know it -- because without that knowledge they won't have the
search terms needed to find it in Google.  I don't, and I imagine you
don't, think it's a good idea to abandon the tracker and discuss those
issues here instead.  Eventually we'll have technology to aggregate
that, I hope.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] python-3.4.0

[Greg Mildenstein]

Hi,
 
I'm running windows 8.1 64 bit. I was using 'python-3.3.1.amd64' but have 
uninstalled it and installed the above version. However, when I try running 
'PyScripter', I get an error stating, 'ERROR - unable to open python, it will 
now exit'. Is there something I'm doing wrong?
 
Thanks
 
Greg Mildenstein
  ___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python-3.4.0

[Zachary Ware]

On April 13, 2014 10:31:24 AM CDT, Greg Mildenstein 
 wrote:
>Hi,
> 
>I'm running windows 8.1 64 bit. I was using 'python-3.3.1.amd64' but
>have uninstalled it and installed the above version. However, when I
>try running 'PyScripter', I get an error stating, 'ERROR - unable to
>open python, it will now exit'. Is there something I'm doing wrong?

Hi Greg,

All you've done wrong is use the wrong list for your question ;-).  Python-dev 
is intended for discussing the development *of* Python, not development *with* 
Python. Python-list would have been a better choice of venue, or a 
PyScripter-specific discussion forum.

That said, the problem you're having is because PyScripter has not yet been 
updated to run with Python 3.4. If you want to stick with PyScripter, you'll 
have to reinstall Python 3.3 (though I would suggest updating to 3.3.5 instead 
of 3.3.1). You can install both versions side-by-side without any problems. If 
you want an IDE that can run Python 3.4, you'll need to use something else 
until PyScripter updates.

Hope this helps,
--
Zach (on a phone)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Antoine Pitrou]

Le 13/04/2014 03:07, Benjamin Peterson a écrit :

On Sat, Apr 12, 2014, at 17:30, Stephen J. Turnbull wrote:

I apologize for the tone.  I need to go *right* now, and can't fix
that.  Really, I'm sympathetic and my goal is not just to defend
python-dev, but to help you get the reviews your work deserves.
Please read with that in mind.


I don't think Nikolaus is wrong to post here. I often tell people that
sometimes the only way to get your patches in is to constantly poke us
about it.



FWIW - I agree with Benjamin, there's nothing wrong in posting here.

Regards

Antoine.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 Windows installers (Was: death to 2.7; long live 2.7)

[Martin v. Löwis]

Am 10.04.14 03:22, schrieb Benjamin Peterson:
> We'll keep doing what we're currently doing for another year, making
> normal bug fix releases with installers. After that, we _won't_ close
> 2.7 to normal bug fixes as is currently implied by the release schedule.

After thinking about this plan, I believe it is best if I step down as
the Windows installers engineer right away. To my knowledge, no specific
date for the next 2.7 bugfix release has been set, so this should allow
to find a replacement before the next release.

I would have volunteered to do two more releases if these had been the
definite last ones, as it would have been impractical to replace me for
just two releases. If this is going until 2020, anybody up to the task
should start working on it now.

I'll be willing to help anybody taking over with advise, but I'll
consider the 2.7 branch otherwise dead (i.e. not worthwhile
contributing to).

I'll be happy to continue making installers for the 3.x branches,
but if anybody considering to volunteer would do so on the condition
that he/she gets it "all", I'd be happy to hand these other branches
over as well.

Of course, anybody taking over that role would be free to either keep
or replace the current technology (e.g. switching to InstallShield
or WiX or whatever).

The one option I'd rather not support is an "open" committee of
Windows installer engineers. Anybody taking this role will have a
copy of the PSF code signing key, so I'd like to keep this list
rather small, and the people attached to the task.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Martin v. Löwis]

Am 13.04.14 03:07, schrieb Benjamin Peterson:
> On Sat, Apr 12, 2014, at 17:30, Stephen J. Turnbull wrote:
>> I apologize for the tone.  I need to go *right* now, and can't fix
>> that.  Really, I'm sympathetic and my goal is not just to defend
>> python-dev, but to help you get the reviews your work deserves.
>> Please read with that in mind.
> 
> I don't think Nikolaus is wrong to post here. I often tell people that
> sometimes the only way to get your patches in is to constantly poke us
> about it.

I agree. If I had more time than I actually do, I would have responded
with my 5-for-1 deal. Instead, I just looked at some of the patches,
and commented on further improvements.

As for the request "Are you sure that the patch is ready": this is
*very* difficult to answer for the author. We all have experienced
that patches that we considered good were critized out of nowhere,
and I just did the same to Nikolaus. There is just no way to tell
in advance whether people will approve a certain change or not, because
people will apply other criteria than oneself.

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Martin v. Löwis]

Am 13.04.14 08:36, schrieb Stephen J. Turnbull:

> I admit the tone was biased toward nagging or "blaming the victim",
> and again I apologize for causing misunderstanding.  Nikolaus isn't
> "wrong" for posting here.  My claim is that in current circumstances,
> core-mentorship would be a more *effective* channel because
> 
>  - core-mentorship is *explicitly* for poking Those Who Can Help
>(among other requests for help);

It would be worth an experiment. I know that I wouldn't have reviewed
Nikolaus' patches if he had posted to core-mentorship - I'm not a core
mentor.

> I also suggested that some tweaks to the weekly issue report might
> help to catch the attention of those who can commit patches, but my
> ideas about that are still basically vaporware.

Well, the code of the weekly reports is free software, contributions
are welcome :-)

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows installers and OpenSSL

[Martin v. Löwis]

Am 10.04.14 15:41, schrieb Paul Moore:
> Given the OpenSSL vulnerability and the fact that we bundle OpenSSL
> with the Windows installers (1.0.1e in Python 3.4.0) should we be
> releasing updated installers?

As others have said: certainly, and only for 3.4.0 (i.e. 2.7 in
particular is not affected - I'm glad I didn't update OpenSSL
there past 0.9.8).

My feeling with these things is that it is often better to wait
until the dust settles - people in a hurry of fixing security
bugs tend to introduce new ones in the process.

I'm tempted to experiment with installer patch files for this
(.msp); it's technically just a single DLL that would need to be
replaced. Contributions are welcome.

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Terry Reedy]

On 4/13/2014 2:46 PM, "Martin v. Löwis" wrote:


As for the request "Are you sure that the patch is ready": this is
*very* difficult to answer for the author. We all have experienced
that patches that we considered good were critized out of nowhere,
and I just did the same to Nikolaus. There is just no way to tell
in advance whether people will approve a certain change or not, because
people will apply other criteria than oneself.


What I suggested is that he make sure that the patch *appears* to be 
ready, as far as he can tell, according to our *minimum* criteria -- and 
that he so indicate. There is a big difference between a bare code patch 
and a whitespace-tested code + test + doc + ack patch, with a news entry 
suggested only in the text, if at all.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows installers and OpenSSL

[Steve Dower]

I'm willing to embark on migrating the entire installer to WiX, which doesn't 
directly fix any particular issue, but could significantly reduce the overhead 
of building and maintaining the Windows installers.

Martin - are you at PyCon today? Can we chat to figure out what how much of the 
work you do can be automated? (If not, email on or off list is good too.)

Alternatively, if you don't want me mucking about with this, tell me and I'll 
stop (being willing does not mean being keen ;) )

Cheers,
Steve

Top-posted from my Windows Phone

From: Martin v. Löwis
Sent: ‎4/‎13/‎2014 14:51
To: Paul Moore; Python 
Dev
Subject: Re: [Python-Dev] Windows installers and OpenSSL

Am 10.04.14 15:41, schrieb Paul Moore:
> Given the OpenSSL vulnerability and the fact that we bundle OpenSSL
> with the Windows installers (1.0.1e in Python 3.4.0) should we be
> releasing updated installers?

As others have said: certainly, and only for 3.4.0 (i.e. 2.7 in
particular is not affected - I'm glad I didn't update OpenSSL
there past 0.9.8).

My feeling with these things is that it is often better to wait
until the dust settles - people in a hurry of fixing security
bugs tend to introduce new ones in the process.

I'm tempted to experiment with installer patch files for this
(.msp); it's technically just a single DLL that would need to be
replaced. Contributions are welcome.

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] static typing of input arguments in signatures

[Terry Reedy]

On 4/13/2014 4:11 AM, Łukasz Langa wrote:

On Apr 13, 2014, at 12:48 AM, Stefan Behnel  wrote:


Stefan Behnel, 12.04.2014 19:11:

So, what I've learned from seven years of Cython is that static typing in
signatures is actually less interesting than you might think at first
sight. It might be ok for documentation purposes, although its verboseness
makes that also a bit questionable.


You raise a valid point that type hinting a dict instead of a Mapping is
likely to create an overly limiting API. This sort of error is however
quite easy to fix forward.

To counter, we’ve had multiple data points during the summit suggesting
that duck typing is not really that often used in production code. In
other words, after initial prototyping and testing, an API of a callable
gets settled and is later used with a very limited number of types.


For public library code, where the use case is not known, apis should 
usually be as generic as sensible. For private library code, I can 
imagine that apis are and possibly even should be limited to classes 
actually used. There naturally is a bit of a bias here for public code.



Of course, fuzzy terms like “often”, “seldom”, and “limited” suggest
that we don’t have hard data here. That being said, there is a clear
need to improve our ability to lint code, refactor code easier, and
document the contracts better. This has been voiced by various
conference attendees and the consensus is tremendous.


This need applies to public as well as private code. Private code is a 
good place for experiments.



For Python specifically the existence of prototypes like Mypy, obiwan,
or pytypedecl shows that there is growing interest in standardizing this
functionality. Therefore, I'm drafting a PEP for opt-in type hints with
optional checks at runtime and by static analysis. Will post the initial
form in the upcoming days, and then we can go paint that bike shed.


I look forward to it.


I'm aware that great care here is needed for the outcome to feel
Pythonic and not overwhelming. Don't worry before you get your hands on
the draft, though.


I'm not. PEPs routinely get revised, and ofter improved, no matter the 
author.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 Windows installers (Was: death to 2.7; long live 2.7)

[Steve Dower]

I replied to the other email before I saw this one.

Consider this my self-nomination to take over, pending a quick email to 
Microsoft's lawyers to make sure it's okay (it should be, but IANAL and they 
wrote the policy).

My plan would be to rewrite the installer using WiX but retaining compatibility 
with the existing MSIs. I'd also automate as much as possible to make it very 
easy for someone else with the certificates to build/verify the release.

Happy to answer any other questions or provide more background about myself if 
people ask.

Cheers,
Steve

Sent from my Windows Phone

From: Martin v. Löwis
Sent: ‎4/‎13/‎2014 14:29
To: Benjamin Peterson; 
python-dev@python.org
Subject: Re: [Python-Dev] 2.7 Windows installers (Was: death to 2.7; long live 
2.7)

Am 10.04.14 03:22, schrieb Benjamin Peterson:
> We'll keep doing what we're currently doing for another year, making
> normal bug fix releases with installers. After that, we _won't_ close
> 2.7 to normal bug fixes as is currently implied by the release schedule.

After thinking about this plan, I believe it is best if I step down as
the Windows installers engineer right away. To my knowledge, no specific
date for the next 2.7 bugfix release has been set, so this should allow
to find a replacement before the next release.

I would have volunteered to do two more releases if these had been the
definite last ones, as it would have been impractical to replace me for
just two releases. If this is going until 2020, anybody up to the task
should start working on it now.

I'll be willing to help anybody taking over with advise, but I'll
consider the 2.7 branch otherwise dead (i.e. not worthwhile
contributing to).

I'll be happy to continue making installers for the 3.x branches,
but if anybody considering to volunteer would do so on the condition
that he/she gets it "all", I'd be happy to hand these other branches
over as well.

Of course, anybody taking over that role would be free to either keep
or replace the current technology (e.g. switching to InstallShield
or WiX or whatever).

The one option I'd rather not support is an "open" committee of
Windows installer engineers. Anybody taking this role will have a
copy of the PSF code signing key, so I'd like to keep this list
rather small, and the people attached to the task.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Nikolaus Rath]

Terry Reedy  writes:
[Quote conveniently rearranged]
>> I've accumulated a number of patches in the issue tracker that are
>> waiting for someone to review/commit/reject them. I'm eager to make
>> corrections as necessary, I just need someone to look the work that I've
>> done so far:
>
> Do you consider any of these 'ready-to-commit'?
> * before-fail, after-pass test?
> * required doc changes?
> * tested patch for all versions that should be patched?
> * any new Misc/ACKS entry needed (for new person other than you)?
> * checked for stray end-of-line whitespace?

Actually, they should all be in this stage (assuming make patchcheck
would complain about eol whitespace). I wouldn't call it ready-to-commit
though, I'm sure a second pair of eyes would find issues that need to be
addressed. But I'm at a point where I don't see any possible issues.

In more detail:

>> * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for
>>non-blocking socket)

This contains a docpatch for 3.4 that (I believe) should be applied in
any case. In addition, there does not seem to be a consensus whether the
same behavior should be kept for 3.5 (in that case the docpatch should
be applied for 3.5 as well), deprecated in 3.5 (patch available as
well), or changed right away (no patch attached yet, I'm waiting for
consensus). Maybe it would be enough if some more developers could chime
in? I'm not sure how issues like this are typically decided.

>> * http://bugs.python.org/issue1738 (filecmp.dircmp does exact match
>>only)

Contains testcase, docpatch and code-patch reviewed and updated by
me. New feature, so should go only into 3.5 and applies cleanly.

I just updated the patch to include the original author in Misc/ACKS.

>> * http://bugs.python.org/issue7776 (http.client.HTTPConnection
>>tunneling is broken)

Contains testcase, docpatch and code-patch. Applies cleanly to 3.4, and
I just refreshed the patch for 3.5. Not sure if this should be fixed in
2.7?

>> * http://bugs.python.org/issue20177 (Derby #8: Convert 28 sites to
>>Argument Clinic across 2 files)

No test case and no doc patch necessary (I believe). I have some doubts
about the patch though, see
http://bugs.python.org/issue20177#msg209153. 

>> * http://bugs.python.org/issue19414 (iter(ordered_dict) yields keys
>>not in dict in some circumstances)

There are several different ways to fix this problem. I have created a
patch implementing one of them. It applies cleanly to 3.4 and 3.5 - not
sure why the review link does not show up. I've just attached the same
patch again, maybe that helps.

>> * http://bugs.python.org/issue20578 (BufferedIOBase.readinto1 is
>>missing)

Contains doc update, test case, and code patch. Applies cleanly to 3.5,
and should not go in older versions (new feature).

Martin v. Löwis has kindly started reviewing this.

>> * http://bugs.python.org/issue21057 (TextIOWrapper does not support
>>reading bytearrays or memoryviews)

Contains test case, and code patch. I don't think the documentation
needs to be updated. Patch applies cleanly to 3.5, and should not go in
older versions (new feature).

Martin v. Löwis has kindly started reviewing this as well :-).


Best,
-Nikolaus


-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Nikolaus Rath]

"Stephen J. Turnbull"  writes:
> I apologize for the tone.  I need to go *right* now, and can't fix
> that.  Really, I'm sympathetic and my goal is not just to defend
> python-dev, but to help you get the reviews your work deserves.
> Please read with that in mind.

Will do - but why the rush? Be assured that I would have read the mail
even if it came a day later :-).

> That's an impressive list, but it doesn't tell us what work you've
> done.  There's a checklist in the devguide which should be more
> accurate (sorry about lack of URL), but I imagine it includes the
> following:

>  * Has the issue been classified as bug or feature?
>  * If bug, is it confirmed?
>  * If complex, does it need a PEP?  (probably irrelevant to your patches)
>  * Is there agreement about requirements in the issue comments?
>  * Is there a patch?
>  * Does the design need review?
>  * Has relevant documentation been added/updated (including
>docstrings, manuals, Whats New at least)?
>  * Are there tests that the requirements are satisfied?
>  * Are there tests for any regressions that arose in the process of
>developing the patch?
>  * Have you signed a CA?  (irrelevant to you IIRC)
>  * Is the issue status updated to reflect the work done so far?

I've described the status of each bug in more detail in my reply 
Terry, but generally all the issues contain a testcase (i.e., so I
consider them confirmed), do not require a PEP, contain a patch that
needs review and include documentation updates. I have signed the CA,
and I have updated the issue status as much as I can (I don't seem to
have privileges to add/change keywords). 

I have a second list with issues that I worked on that are more nasty,
but I deliberately did not include them in the list.

> It would help in getting reviewer attention to your work if in
> addition to a list of patches you provided an indication of (1) how
> complete the patch is and (2) what review is requested.  That in
> itself is a strong indicator of quality.

All the patches are complete in the sense that I think they can be
committed and would improve Python. Of course, further improvements are
always possible. I'm not sure about (2) -- what different kind of
reviews are there?


> There must be stuff of interest to you happening on twitter, etc.,
> during PyCon.

I'm not quite sure what you're getting at (maybe because I don't use
twitter).

Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Nikolaus Rath]

"Martin v. Löwis"  writes:
> Am 13.04.14 08:36, schrieb Stephen J. Turnbull:
>
>> I admit the tone was biased toward nagging or "blaming the victim",
>> and again I apologize for causing misunderstanding.  Nikolaus isn't
>> "wrong" for posting here.  My claim is that in current circumstances,
>> core-mentorship would be a more *effective* channel because
>> 
>>  - core-mentorship is *explicitly* for poking Those Who Can Help
>>(among other requests for help);
>
> It would be worth an experiment. I know that I wouldn't have reviewed
> Nikolaus' patches if he had posted to core-mentorship - I'm not a core
> mentor.

This is actually not the first time I sent this (though luckily, the
number of issues did change somewhat since the last attempt). My last
two mails went to core-mentorship, so I figured that maybe this time I
ought to try a different list to get other people's attention as well.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows installers and OpenSSL

[Martin v. Löwis]

Am 13.04.14 21:41, schrieb Steve Dower:
> I'm willing to embark on migrating the entire installer to WiX, which
> doesn't directly fix any particular issue, but could significantly
> reduce the overhead of building and maintaining the Windows installers.

I somewhat doubt that it could reduce the overhead - the actual
overhead for the MSI generation is fairly small. It's more that the
current Python-based approach is not too familiar to people, in
particular to those that are familiar with WiX (which I, in turn, am
not).

> Martin - are you at PyCon today? Can we chat to figure out what how much
> of the work you do can be automated? (If not, email on or off list is
> good too.)

Unfortunately, I'm not, and I can't really do chats ATM due to timezone
differences. It's all fairly automated; what takes time is that there
is manual steps in-between (e.g. getting the sources from Mercurial,
launching Visual Studio, running the CHM generator, running the MSI
generator, signging with PGP, uploading the files, running the
installer for testing, uninstalling the previous installation, and so
on). It could be done in a single batch file mostly, except that I
never got to write this batch file.

If it's automated, it would still take an hour or so, but it would be
possible to do other things while waiting for the build to complete.

> Alternatively, if you don't want me mucking about with this, tell me and
> I'll stop (being willing does not mean being keen ;) )

If it's that, I'd say stop. It's not that I want you to, but that I'm
skeptical that it solves anything. If you do want to start using WiX,
please do run the current build process at least once before.

The basic instruction for that is "run msi.py". It will tell you
if it's missing files, and anybody familiar with the build process
should be able to figure out how to get the missing files (if not,
just ask).

Regards,
Martin



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 2.7 Windows installers (Was: death to 2.7; long live 2.7)

[Martin v. Löwis]

Am 13.04.14 22:02, schrieb Steve Dower:
> I replied to the other email before I saw this one.

Same here :-)

> Consider this my self-nomination to take over, pending a quick email to
> Microsoft's lawyers to make sure it's okay (it should be, but IANAL and
> they wrote the policy).
> 
> My plan would be to rewrite the installer using WiX but retaining
> compatibility with the existing MSIs. I'd also automate as much as
> possible to make it very easy for someone else with the certificates to
> build/verify the release.
> 
> Happy to answer any other questions or provide more background about
> myself if people ask.

As I just said: to get started, run the current build process. Without
knowing WiX in detail, I'd still claim that msi.py is superiour in
terms of expressiveness (i.e. it can better compute what files go into
the MSI). I'm almost certain that you need a full programming language
to actually perform the entire build; one alternative to msi.py would
be to have a Python script generating the WiX configuration files.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] static typing of input arguments in signatures

[R. David Murray]

On Sun, 13 Apr 2014 15:59:36 -0400, Terry Reedy  wrote:
> On 4/13/2014 4:11 AM, Łukasz Langa wrote:
> > On Apr 13, 2014, at 12:48 AM, Stefan Behnel  wrote:
> >
> >> Stefan Behnel, 12.04.2014 19:11:
> >>
> >> So, what I've learned from seven years of Cython is that static typing in
> >> signatures is actually less interesting than you might think at first
> >> sight. It might be ok for documentation purposes, although its verboseness
> >> makes that also a bit questionable.
> >
> > You raise a valid point that type hinting a dict instead of a Mapping is
> > likely to create an overly limiting API. This sort of error is however
> > quite easy to fix forward.
> >
> > To counter, we’ve had multiple data points during the summit suggesting
> > that duck typing is not really that often used in production code. In
> > other words, after initial prototyping and testing, an API of a callable
> > gets settled and is later used with a very limited number of types.
> 
> For public library code, where the use case is not known, apis should 
> usually be as generic as sensible. For private library code, I can 
> imagine that apis are and possibly even should be limited to classes 
> actually used. There naturally is a bit of a bias here for public code.

The way *I* heard it was that types of the input arguments did not, in
general, change *during the running of an application*.  That doesn't
mean that the types wouldn't be different in a different application,
which means that in a library that duck types, duck typing is indeed used
in production, it's just that the types don't *change* for a production
application.  So, yeah, pretty much what Terry said about library code
versus application code.  That is, after all, what duck typing is about,
and there is a *reason* we use it.

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Stephen J. Turnbull]

Nikolaus Rath writes:

 > I've described the status of each bug in more detail in my reply 
 > Terry, but generally all the issues contain a testcase (i.e., so I
 > consider them confirmed), do not require a PEP, contain a patch that
 > needs review and include documentation updates. I have signed the CA,
 > and I have updated the issue status as much as I can (I don't seem to
 > have privileges to add/change keywords). 

AFAIK that can be described as:

 > All the patches are complete in the sense that I think they can be
 > committed and would improve Python.

I don't suggest you need to say more than that.  Perhaps I overlooked
such a statement in the OP?  If so, I'm sorry.

For somebody who is submitting their first round of patches I would
recommend some statement indicating that they know about the
"checklist" you described above, but by now you're well-known to the
Right People.

 > Of course, further improvements are always possible.

Your modesty is not in question. :-)  An explicit statement that "These
are ready" allows an experienced developer to give you feedback not
only about whether the patches are in fact ready, but whether your
judgment about patches is ready for commit privileges -- in Python
it's desirable that code be "Pythonic" as well as correct and clean.

 > I'm not sure about (2) -- what different kind of reviews are there?

>From the contributor point of view, I'd broadly say

 - I'm stuck (this is harder than I thought), somebody please look at
   what I've done and tell me I haven't screwed up so far, and then
   I'll go back to work.

 - I'm a little stuck, maybe I'm done, but I'm not sure.  Please look.

 - I'm done, please commit it if you agree.

Evidently you specifically listed patches for which you want an "I'm
done" review.  Part of why I wrote what I did is that I didn't
recognize that.

 > > There must be stuff of interest to you happening on twitter, etc.,
 > > during PyCon.
 > 
 > I'm not quite sure what you're getting at (maybe because I don't use
 > twitter).

Just that on the one hand, it was very obvious to me that over the
last few weeks people were very busy preparing for PyCon (and so even
less time than usual for reviewing), and on the other, if you can't be
at PyCon, there's much to hear about Python design and implementation,
and about Pythonic thinking by following the language summit and what
people are talking about during PyCon.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: Jython Report

[Guido van Rossum]

Jim and Frank,

I just wanted to thank you both (and all other Jython developers) for
sending this update, and for your great and continued work on Jython. I'm
sorry neither of you could come to PyCon but I am very happy that the torch
is being carried!! It's a fantastic list indeed.

--Guido


On Sat, Apr 12, 2014 at 11:56 AM, Michael Foord wrote:

> Below is the Jython "status update" report on Jython I received from Jim
> Baker and summarised in the Language Summit. It comes with one addendum
> from Frank:
>
> Jim's list is fantastic - the one bit I'd like to add to the list:
>
> Jython now supports a buffer protocol that parallels CPython's C API
> buffer protocol. This provided the basis for support of buffer() and
> memoryview(). The work was done with Jython3 in mind and will be a huge
> boost to that eventual effort.
>
> Begin forwarded message:
>
> *From: *Jim Baker 
> *Subject: **Re: Jython Report*
> *Date: *7 April 2014 06:42:51 BST
> *To: *Michael Foord 
> *Cc: *Frank Wierzbicki 
>
> Recent changes to trunk (last 6 months)
>
> * Recently tagged a soft beta 2!
> * Java 7 JVM is now the minimum version, which gives a larger base of
> functionality to work with (such as using Java 7's AutoCloseable to imply
> corresponding context manager support in using Python code)
> * Enable mixing Python and Java types in the bases of a class when using a
> metaclass
> * Added support for buffer, memoryview, although not complete yet with
> respect to Java integration
> * Console and encoding support, such as unicodedata/idna updates
> * Many, many small fixes
>
> About to be in trunk, to support beta 3
>
> * socket-reboot reimplements socket/select/ssl on top of Netty 4, a
> popular event loop networking framework for the JVM (used by a large number
> of performant projects in Java space and originally part of JBoss). There
> was no ssl support before, but now socket and especially select semantics
> are much closer to CPython as well (basically close to the Windows socket
> model).
> * socket-reboot in turn enables requests and thereby pip. A branch of pip
> currently works, actually modifying an upstream vendor lib (html5lib) so
> that it doesn't use isolated UTF-16 surrogates in literals, since this is
> not actually legal unicode, nor does it work in Jython's UTF-16 based
> representation. Ironically this usage is to detect such illegal use in
> input streams.
> * Relative star imports, which seems to impact a number of interesting
> projects.
> * Performance tuning of sre. Jython has a port of CPython's sre, however
> our use of UTF-16 requires expansion into an array of codepoints. Currently
> this is done on demand, which can potentially add another O(n) factor in
> evaluating regexes. A pull request we will apply memoizes. In the future,
> we will rewrite the logic in sre so that it does next/prev, much like JRuby
> currently does for similar encoding issues.
>
> Related work
>
> * Other PyPA tooling including virtualenv and wheel needs more diagnosis
> to see why they currently fail on Jython, but our hope is that this is
> minor.
> * New project jythontools by a number of Jython developers (including
> Frank and Jim). This includes a number of projects that will help evolve
> Jython, but outside the usual release schedule and the usual problem of
> being in core (such as eventual deprecation):
>   - Clamp - precise integration with Java, enabling such capabilities
> as Java directly importing Python modules without explicitly initializing
> the Jython runtime or using object factories. Future work will enable Java
> annotation integration, as decorators. Integrates with setuptools; future
> integration as well with Maven via Aether.
>   - Jiffy - provide a CFFI backend for Jython. Right now it is pure
> vaporware, but cursory examination of cffi.backend_ctypes suggests that it
> should be straightforward and of modest effort to provide a similar backend
> by using JFFI, which Jython and JRuby both use to access native runtime
> services (such as Posix API) as part of the Java native runtime project.
> * The Patois project has been started to collect examples for
> cross-implementation support, as seen in surrogate support, but it will be
> a good question to get that really going, vs just talking about it.
> * JyNI - simply adding this jar to the classpath enables C extension API
> support. Note that this project has been licensed by its developer (not a
> Jython committer) under an LGPL license.
>
> Release schedule
>
> * Complete beta 2
> * Beta 3 is forthcoming, likely in 2 weeks
> * For beta 4, need to perform a comprehensive bug triage - what will be
> in, not in for 2.7.0
> * EuroPython sprint to finalize a release candidate for 2.7.0?
>
> Future
>
> * Mostly around performance, Java integration, and of course the usual bug
> fixes
> * Python bytecode compiler remains important, including for support
> targeting Android and removing restriction on getting too large a method
> for the 

Re: [Python-Dev] Appeal for reviews

[Stephen J. Turnbull]

"Martin v. Löwis" writes:
 > Am 13.04.14 08:36, schrieb Stephen J. Turnbull:

 > >  - core-mentorship is *explicitly* for poking Those Who Can Help
 > >(among other requests for help);
 > 
 > It would be worth an experiment. I know that I wouldn't have reviewed
 > Nikolaus' patches if he had posted to core-mentorship - I'm not a core
 > mentor.

I imagine there's useful data on this already available.  I'll go
look, in a week or two.

 > > I also suggested that some tweaks to the weekly issue report might
 > > help to catch the attention of those who can commit patches, but my
 > > ideas about that are still basically vaporware.
 > 
 > Well, the code of the weekly reports is free software, contributions
 > are welcome :-)

XEmacs uses roundup, too, including (a now-obsolete version of) the
Python patches.  Time horizon is longer, but I may look into this too.

Note that what I have in mind also may require changes to the schema,
I believe (there needs to be a user control to mark the issue as
"commit requested", and I don't think a keyword would be appropriate).

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[martin]

Quoting "Stephen J. Turnbull" :


Your modesty is not in question. :-)  An explicit statement that "These
are ready" allows an experienced developer to give you feedback not
only about whether the patches are in fact ready, but whether your
judgment about patches is ready for commit privileges -- in Python
it's desirable that code be "Pythonic" as well as correct and clean.


For a regular patch, I think this is asking to much. The default
assumption should be that the patch is finished, and not work-in-progress.
If it was, people typically indicate so. But I then regularly ask that
the tracker is not abused as a version control system to develop a
change; it's easy enough to use a Mercurial clone for that.

For gaining commit access, it's really more important that the patch
is factually finished, than that it's author believes it to. If people
get it right the first time often enough, they get commit access.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] your next regular installment of python 2.7

[Benjamin Peterson]

Yep, it's almost that time of the year again. My proposed schedule for
2.7.7 is

May 12th, 2.7.7rc1
May 26th, 2.7.7 final

That means if you want your 2.7 improvement to see the light of day
before November, the next few weeks are the time to do it. (PEP 446, I'm
looking at you.)

Also, I doubt anyone cares, but I'm going to do the last security
release of python 3.1 concurrently. That will, of course, be a
source-only release.

Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Appeal for reviews

[Stephen J. Turnbull]

mar...@v.loewis.de writes:

 > For gaining commit access, it's really more important that the patch
 > is factually finished, than that it's author believes it to. If people
 > get it right the first time often enough, they get commit access.

Yes, that's what I had in mind, but I guess I explained it poorly.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com