Re: [Python-Dev] Python 3.6.0rc2 coming soon, 3.6.0 final now 2016-12-23

2016-12-16 Thread Victor Stinner 
Ned Deily:
> Alas, in the last few days at least one outstanding issue that we had hoped 
> would not be a real-world problem has proven to be a showstopper during 
> third-party package testing and I have been persuaded that we do need to fix 
> it before 3.6.0 final.  I take responsibility and apologize for not ensuring 
> it was resolved earlier in the release cycle; I'll try to do better next time.

No need to apologize, you are doing a great job! I'm not surprised at
all that major bugs are still found just a few days before the final
release: many people wait just before a final release to test their
code.

I'm happy that such bugs are found _before_ a release. Bugs like "my
applications takes 4 GB of memory with Python 3.6 but 40 MB with
Python 3.5" (#28147) seem so big that it would be a shame to "ship"
such bug in a final release!


> FYI: Here is a list of the post 3.6.0rc1 changesets that have been 
> cherrypicked so far for 3.6.0rc2.  There will likely be at least one more.  
> (Note, the description and files list below for some changesets may be 
> truncated.)

test_gdb is broken in the RC1. To fix test_gdb, I convinced Ned to
also cherry-pick:
---
changeset:   105342:752863f96fb8
user:Victor Stinner 
date:Tue Nov 22 22:53:18 2016 +0100
files:   Lib/test/test_gdb.py Tools/gdb/libpython.py
description:
Issue #28770: Update python-gdb.py for fastcalls

Frame.is_other_python_frame() now also handles _PyCFunction_FastCallDict()
frames.

Thanks to the new code to handle fast calls, python-gdb.py is now also able to
detect the  frame.


Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cleanup of abstract.h header

2016-12-16 Thread Antoine Pitrou 
On Thu, 15 Dec 2016 11:22:10 +0100
Victor Stinner  wrote:
> 
> Before:
> https://hg.python.org/cpython/file/f692dafe6797/Include/abstract.h
> 
> Now:
> https://hg.python.org/cpython/file/c4bcca326c0a/Include/abstract.h

Since you are cleaning up, you could remove the whole "PROPOSAL: A
Generic Python Object Interface for Python C Modules" introduction,
which isn't very interesting to read today.

Regards

Antoine.


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

[Python-Dev] Last call for the Call For Proposals of PythonFOSDEM 2017

2016-12-16 Thread Stephane Wirtel via Python-Dev 
Hello, this week-end is the last two days for the Call For Proposals of 
PythonFOSDEM 2017. We have received a lot of topics, but if you want to 
become a speaker and that you have a very cool topic to submit, please 
don't hesite and send us your proposal.


Deadline is 2016-12-18.

Stephane


Call For Proposals
==

This is the official call for sessions for the Python devroom at FOSDEM 2017.

FOSDEM is the Free and Open source Software Developers' European Meeting, a free
and non-commercial two-day week-end that offers open source contributors a place
to meet, share ideas and collaborate.

It's the biggest event in Europe with +5000 hackers, +400 speakers.

For this edition, Python will be represented by its Community.
If you want to discuss with a lot of Python Users, it's the place to be!

Important dates
===

* Submission deadlines: 2016-12-18
* Acceptance notifications: 2016-12-23

Practical
=

* The duration for talks will be 30 minutes, including presentations and
questions and answers.
* Presentation can be recorded and streamed, sending your proposal implies
giving permission to be recorded.
* A mailing list for the Python devroom is available for discussions about
devroom organisation. You can register at this address:
https://lists.fosdem.org/listinfo/python-devroom

How to submit
=

All submissions are made in the Pentabarf event planning tool at
https://penta.fosdem.org/submission/FOSDEM17

When submitting your talk in Pentabarf, make sure to select the Python devroom
as the Track.

Of course, if you already have a user account, please reuse it.

Questions
=

Any questions, please send an email to info AT python-fosdem DOT org

Thank you for submitting your sessions and see you soon in Brussels to talk
about Python.

If you want to keep informed for this edition, you can follow our twitter
account @PythonFOSDEM.

* FOSDEM 2017: https://fosdem.org/2017
* Python Devroom: http://python-fosdem.org
* Twitter: https://twitter.com/PythonFOSDEM


Stephane

--
Stéphane Wirtel - http://wirtel.be - @matrixise
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cleanup of abstract.h header

2016-12-16 Thread Victor Stinner 
2016-12-16 11:24 GMT+01:00 Antoine Pitrou :
> Since you are cleaning up, you could remove the whole "PROPOSAL: A
> Generic Python Object Interface for Python C Modules" introduction,
> which isn't very interesting to read today.

Ah right, I noticed this huge comment but I didn't understand the
purpose. IMHO https://docs.python.org/dev/c-api/ is now a much better
documentation for the Python C API. I agree to remove the long
introduction.

By the way, I'm surprised by the "many thanks to Jim Fulton" in the
comment, since I'm not sure to what it is referred to. But in case of
doubt, I prefer to keep it :-)

/* Abstract Object Interface (many thanks to Jim Fulton) */

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Cleanup of abstract.h header

2016-12-16 Thread Guido van Rossum 
Many eons ago, Jim created abstract.h. The proposal comment (which you're
right to be cutting out now) was his and at some point it was accepted, but
I just copied-pasted the whole text into abstract.h. So yes, please keep
the "many thanks to Jim Fulton" in there!

On Fri, Dec 16, 2016 at 7:03 AM, Victor Stinner 
wrote:

> 2016-12-16 11:24 GMT+01:00 Antoine Pitrou :
> > Since you are cleaning up, you could remove the whole "PROPOSAL: A
> > Generic Python Object Interface for Python C Modules" introduction,
> > which isn't very interesting to read today.
>
> Ah right, I noticed this huge comment but I didn't understand the
> purpose. IMHO https://docs.python.org/dev/c-api/ is now a much better
> documentation for the Python C API. I agree to remove the long
> introduction.
>
> By the way, I'm surprised by the "many thanks to Jim Fulton" in the
> comment, since I'm not sure to what it is referred to. But in case of
> doubt, I prefer to keep it :-)
>
> /* Abstract Object Interface (many thanks to Jim Fulton) */
>
> Victor
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2016-12-16 Thread Python tracker 

ACTIVITY SUMMARY (2016-12-09 - 2016-12-16)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open5639 (+18)
  closed 35107 (+50)
  total  40746 (+68)

Open issues with patches: 2443 


Issues opened (53)
==

#20754: Distribution.parse_config_files uses interpolation since Pytho
http://bugs.python.org/issue20754  reopened by jason.coombs

#28770: Update python-gdb.py for fastcalls
http://bugs.python.org/issue28770  reopened by ned.deily

#28923: Nonexisting encoding specified in Tix.py
http://bugs.python.org/issue28923  opened by Ivan.Pozdeev

#28926: subprocess.Popen + Sqlalchemy doesn't wait for process
http://bugs.python.org/issue28926  opened by s1113950

#28927: bytes.fromhex should ignore all whitespace
http://bugs.python.org/issue28927  opened by nneonneo

#28929: Provide a link from documentation back to its source file
http://bugs.python.org/issue28929  opened by brett.cannon

#28931: urllib ignores FTP 226 response, breaking further FTP requests
http://bugs.python.org/issue28931  opened by Ivan.Pozdeev

#28932: Fail compile Python 3.6.0rc1 on OpenBSD 6.0
http://bugs.python.org/issue28932  opened by shadchin

#28934: _mboxMMDF#get_message should delegate to get_bytes
http://bugs.python.org/issue28934  opened by bpoaugust

#28936: test_global_err_then_warn in test_syntax is no longer valid
http://bugs.python.org/issue28936  opened by serhiy.storchaka

#28937: str.split(): remove empty strings when sep is not None
http://bugs.python.org/issue28937  opened by barry

#28938: match_hostname treats SAN IP address as DNS name and fails to 
http://bugs.python.org/issue28938  opened by noxxi

#28940: __length_hint__ isn't a hint for list()
http://bugs.python.org/issue28940  opened by ronaldoussoren

#28941: Update the link to Source Code in Python Docs from hg to githu
http://bugs.python.org/issue28941  opened by Mariatta

#28942: await expressions in f-strings
http://bugs.python.org/issue28942  opened by Adam Gregory

#28945: get_boundary invokes unquote twice
http://bugs.python.org/issue28945  opened by bpoaugust

#28948: Facing issue while running Python 3.6.0rc1 windows x86-64 web 
http://bugs.python.org/issue28948  opened by arpit arora

#28949: Stdlib modules disappear from file system
http://bugs.python.org/issue28949  opened by jason.coombs

#28950: regrtest: -j0 fails the check -j is not allowed together with 
http://bugs.python.org/issue28950  opened by xiang.zhang

#28951: re.flags not documented in Module Contents as promised.
http://bugs.python.org/issue28951  opened by 4Dummies

#28952: csv.Sniffer().sniff(0 returns a value without the "strict" att
http://bugs.python.org/issue28952  opened by 4Dummies

#28953: Use `raise from` when raising new IncompleteRead
http://bugs.python.org/issue28953  opened by cool-RR

#28954: Incorrect EBNF rule of keywords_arguments
http://bugs.python.org/issue28954  opened by woo yoo

#28955: Not matched behavior of numeric comparison with the documentat
http://bugs.python.org/issue28955  opened by woo yoo

#28956: return minimum of modes for a multimodal distribution instead 
http://bugs.python.org/issue28956  opened by sria91

#28957: undefined symbol: PyUnicodeUCS2_FromUnicode when executing any
http://bugs.python.org/issue28957  opened by rkommine

#28958: Python should return comperhansive error when SSLContext canno
http://bugs.python.org/issue28958  opened by Ilya.Kulakov

#28960: Small typo in Thread.join docs
http://bugs.python.org/issue28960  opened by rcorre

#28961: unittest.mock._Call ignores `name` parameter
http://bugs.python.org/issue28961  opened by Jiajun Huang

#28962: Crash when throwing an exception with a malicious __hash__ ove
http://bugs.python.org/issue28962  opened by Jelle Zijlstra

#28963: Use-after-free in _asyncio_Future_remove_done_callback() of _a
http://bugs.python.org/issue28963  opened by Ned Williamson

#28964: AST literal_eval exceptions provide no information about line 
http://bugs.python.org/issue28964  opened by stevemerritt

#28965: Multiprocessing spawn/forkserver fails to pass Queues
http://bugs.python.org/issue28965  opened by Sean Murphy

#28967: copy.copy fails on threading.local subclass
http://bugs.python.org/issue28967  opened by Jelle Zijlstra

#28968: xml rpc server fails with connection reset by peer error no 10
http://bugs.python.org/issue28968  opened by manu

#28969: lru_cache is not threadsafe
http://bugs.python.org/issue28969  opened by Nicolas Savoire

#28970: ctypes.from_buffer counterpart to actively remove the mapping
http://bugs.python.org/issue28970  opened by frispete

#28971: nntplib is broken when responses are longer than _MAXLINE
http://bugs.python.org/issue28971  opened by xdegaye

#28972: Document all "python -m" utilities
http://bugs.python.org/issue28972  opened by tebeka

#28973: The fact that multiprocess.Queue uses serialization should be 
http

[Python-Dev] Blockers on GitHub migration and open windows to migrate

2016-12-16 Thread Brett Cannon 
[sending this independently to python-dev and core-workflow]

I have promised Ned that we will not migrate before 3.6.0 is released and
not for a week following in case an emergency 3.6.1 is necessary. I also
promised Larry we wouldn't migrate the week before 3.5.3 is released. That
means the windows for migrating are 2016-12-30 to 2017-01-09, and then any
time after 2016-01-16 (this of course assumes all release schedules don't
slip).

I'm now on vacation until January 3 so I will have time to work on the
migration some more. I will port hg.python.org/lookup to work with git, hg,
and svn probably this week or next. That leaves the only true blockers as
http://psf.upfronthosting.co.za/roundup/meta/issue589 and
http://psf.upfronthosting.co.za/roundup/meta/issue590 (webhook for PR to
issue and notifying an issue when a commit has occurred, respectively; we
already have a GitHub PR field on b.p.o for manual entry). Once those
changes to bugs.python.org land and have been tested live against the
GitHub mirror, we can do the migration (which will most likely take a day
or two). All other issues either require the repo to have already been
migrated and working or can wait post-migration (
https://www.python.org/dev/peps/pep-0512/#cpython-repo).

So if the above wasn't clear, if you want to help then please help with the
b.p.o issues as those are the remaining blockers I can't deal with on my
own. And I actually have GitHub-themed gifts I bought myself sitting under
my Xmas tree that I won't open until we migrate, so let's not take too
long. ;)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Guido van Rossum 
I am beginning to think that `from __future__ import unicode_literals` does
more harm than good. I don't recall exactly why we introduced it, but with
the restoration of u"" literals in Python 3.3 we have a much better story
for writing straddling code that is unicode-correct.

The problem is that the future import does both too much and not enough --
it does too much because it changes literals to unicode even in contexts
where there is no benefit (e.g. the argument to getattr() -- I still hear
of code that breaks due to this occasionally) and at the same time it
doesn't do anything for strings that you read from files, receive from the
network, or even from other files that don't use the future import.

I wonder if we can add an official note to the 2.7 docs recommending
against it? (And maybe even to the 3.x docs if it's mentioned there at all.)

-- 
--Guido van Rossum (python.org/~guido )
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Robert Collins 
On 17 December 2016 at 08:24, Guido van Rossum  wrote:
> I am beginning to think that `from __future__ import unicode_literals` does
> more harm than good. I don't recall exactly why we introduced it, but with
> the restoration of u"" literals in Python 3.3 we have a much better story
> for writing straddling code that is unicode-correct.
>
> The problem is that the future import does both too much and not enough --
> it does too much because it changes literals to unicode even in contexts
> where there is no benefit (e.g. the argument to getattr() -- I still hear of
> code that breaks due to this occasionally) and at the same time it doesn't
> do anything for strings that you read from files, receive from the network,
> or even from other files that don't use the future import.
>
> I wonder if we can add an official note to the 2.7 docs recommending against
> it? (And maybe even to the 3.x docs if it's mentioned there at all.)

I think thats a good idea. I've found u"" to be entirely sufficient
and very robust.

Perhaps also have python2 -3 report on it?

-Rob
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Xavier Combelle 
I personally used it when I was forced to use python 2 and working
mainly with unicode processing (It is particularly handy when working
with json for example)


Le 16/12/2016 à 20:24, Guido van Rossum a écrit :
> I am beginning to think that `from __future__ import unicode_literals`
> does more harm than good. I don't recall exactly why we introduced it,
> but with the restoration of u"" literals in Python 3.3 we have a much
> better story for writing straddling code that is unicode-correct.
>
> The problem is that the future import does both too much and not
> enough -- it does too much because it changes literals to unicode even
> in contexts where there is no benefit (e.g. the argument to getattr()
> -- I still hear of code that breaks due to this occasionally) and at
> the same time it doesn't do anything for strings that you read from
> files, receive from the network, or even from other files that don't
> use the future import.
>
> I wonder if we can add an official note to the 2.7 docs recommending
> against it? (And maybe even to the 3.x docs if it's mentioned there at
> all.)
>
> -- 
> --Guido van Rossum (python.org/~guido )
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/xavier.combelle%40gmail.com

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

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Ethan Furman 

On 12/16/2016 11:24 AM, Guido van Rossum wrote:


I am beginning to think that `from __future__ import unicode_literals` does
 more harm than good. I don't recall exactly why we introduced it, but with
 the restoration of u"" literals in Python 3.3 we have a much better story
 for writing straddling code that is unicode-correct.


So cross-version code would be primarily 2.7 and 3.3+ ?  I can live with that.

--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Chris Angelico 
On Sat, Dec 17, 2016 at 8:07 AM, Ethan Furman  wrote:
> On 12/16/2016 11:24 AM, Guido van Rossum wrote:
>
>> I am beginning to think that `from __future__ import unicode_literals`
>> does
>>  more harm than good. I don't recall exactly why we introduced it, but
>> with
>>  the restoration of u"" literals in Python 3.3 we have a much better story
>>  for writing straddling code that is unicode-correct.
>
>
> So cross-version code would be primarily 2.7 and 3.3+ ?  I can live with
> that.

Or 3.5+ so you get percent formatting for bytes.

+1 for deprecating unicode_literals; I don't remember ever using or wanting it.

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Barry Warsaw 
On Dec 16, 2016, at 01:07 PM, Ethan Furman wrote:

>On 12/16/2016 11:24 AM, Guido van Rossum wrote:
>
>> I am beginning to think that `from __future__ import unicode_literals` does
>>  more harm than good. I don't recall exactly why we introduced it, but with
>>  the restoration of u"" literals in Python 3.3 we have a much better story
>>  for writing straddling code that is unicode-correct.  
>
>So cross-version code would be primarily 2.7 and 3.3+ ?  I can live with that.

So can I.  I don't mind "silently" deprecating it, such as adding strong
admonitions against its use in the docs, but clearly it can't be removed (at
least until 3.7) and I worry about breaking existing code, even with a more
chatty DeprecationWarning.

At least in some circles, the problems of unicode_literals are known, but it's
still useful and it's used in lots of places.  Getting rid of cruft like this
is one of the more satisfying edits when dropping Python 2 support. :)

Cheers,
-Barry
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Cory Benfield 

> On 16 Dec 2016, at 16:07, Ethan Furman  wrote:
> 
> On 12/16/2016 11:24 AM, Guido van Rossum wrote:
> 
>> I am beginning to think that `from __future__ import unicode_literals` does
>> more harm than good. I don't recall exactly why we introduced it, but with
>> the restoration of u"" literals in Python 3.3 we have a much better story
>> for writing straddling code that is unicode-correct.
> 
> So cross-version code would be primarily 2.7 and 3.3+ ?  I can live with that.

Speaking for third-party library authors, almost all cross-version code that 
does anything remotely close to a network is 2.7 and 3.3+. Requests dropped 3.2 
support basically as soon as we could once 3.3’s unicode literals were 
restored, and since then I haven’t written anything that targets 3.2. It’s just 
too frustrating.

And while I’m shoving my oar in, I’ve never seen anyone be happy with using 
“from __future__ import unicode_literals”. As others in this thread have said, 
it just points a loaded gun at your foot and lets you wait for it to go off.

Cory
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/16/2016 04:27 PM, Barry Warsaw wrote:
> Getting rid of cruft like this is one of the more satisfying edits
> when dropping Python 2 support. :)

Ripping it out and replacing with explicit unicode literals is pretty
satisfying when straddling, too. ;)


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYVF7+AAoJEPKpaDSJE9HYSF0P/Ax00KYJQpIQdr7U4vn3Sz6F
CpAfxIxR4uuZJMNwzxl1sBmsJ0xvoO2aldGwbbOzlvlbP1km4MlLfRC/ZFwoKWs0
yDA5xiUrwUGDPME6IEtTzn7CCk5INP6avX2zLkZg6qMfJ9Cd0VJkcJGAXE6CtAwS
swAEJcfeIhb+5gnyHHECLc6XC+LQPf6GHkD0im3ayACr73bMCvdHRYF7pJaZ/XWN
1WYbRlPup0//Ge0MbHAUdn8GwnEm+e2GB1roKEryaSBEHfhtDm1iKPjWeg/gic91
j76nTeQ0qepdjGjGAISiPersSPEW44bzXCSDLh6OfQAUtDqA9pWFbNfOtMkjuM89
+VRC606QinShzwVbmsTbVwl4VAmYqPg/BplteP81nV8uOrsRlFkNJ6oLqhsTM6eM
lFSBGnwDnrP1URt5r2LGs6aKKmZb5aGdW7puYgaaNzrzD5uMW5Kr1B7cPOwP//rD
Y37x4Cu5jq0v9K5yVEc4GbvBdCjgREAUxweS5xUwWoPxFEPcdJiGZqLeYzpV2Llm
K+J+Wa91RdKUtW3G/k16te9QVA0HWFSLMi1+v8XD4xoe3dmktxZeWSa6sUWaDeDT
gso1uABYrvssiNT9+iMLNXNtJ2o4ZytMp6P9uOIUkJWqval1jPzWFZzF5wJA98mI
ebthSapz3wpZQe6+ab17
=frxy
-END PGP SIGNATURE-

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

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Raymond Hettinger 

> On Dec 16, 2016, at 11:24 AM, Guido van Rossum  wrote:
> 
> I am beginning to think that `from __future__ import unicode_literals` does 
> more harm than good. I don't recall exactly why we introduced it, but with 
> the restoration of u"" literals in Python 3.3 we have a much better story for 
> writing straddling code that is unicode-correct.
> 
> The problem is that the future import does both too much and not enough -- it 
> does too much because it changes literals to unicode even in contexts where 
> there is no benefit (e.g. the argument to getattr() -- I still hear of code 
> that breaks due to this occasionally) and at the same time it doesn't do 
> anything for strings that you read from files, receive from the network, or 
> even from other files that don't use the future import.
> 
> I wonder if we can add an official note to the 2.7 docs recommending against 
> it? (And maybe even to the 3.x docs if it's mentioned there at all.)

+1  Leaving it in place will likely cause more problems than it solves, so I 
think your suggest is a net win even if there is some bit of disruption.  Also, 
as far as I can tell, the adoption rate of Python 3.2 was very low.  Python 3's 
story didn't become attractive until later.
  

Raymond
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Jelle Zijlstra 
I've actually found unicode_literals useful in getting code to be Python
2/3-compatible. I try to use a Python 3-like model of always using unicode
for text data and only using str for binary data, and unicode_literals
helps achieve that, since most string literals are meant to be text, not
binary data. The issue with functions like getattr is annoying, but in my
experience it's not a common problem (I don't often call getattr() with a
string literal as an argument).

2016-12-16 14:56 GMT-08:00 Raymond Hettinger :

>
> > On Dec 16, 2016, at 11:24 AM, Guido van Rossum  wrote:
> >
> > I am beginning to think that `from __future__ import unicode_literals`
> does more harm than good. I don't recall exactly why we introduced it, but
> with the restoration of u"" literals in Python 3.3 we have a much better
> story for writing straddling code that is unicode-correct.
> >
> > The problem is that the future import does both too much and not enough
> -- it does too much because it changes literals to unicode even in contexts
> where there is no benefit (e.g. the argument to getattr() -- I still hear
> of code that breaks due to this occasionally) and at the same time it
> doesn't do anything for strings that you read from files, receive from the
> network, or even from other files that don't use the future import.
> >
> > I wonder if we can add an official note to the 2.7 docs recommending
> against it? (And maybe even to the 3.x docs if it's mentioned there at all.)
>
> +1  Leaving it in place will likely cause more problems than it solves, so
> I think your suggest is a net win even if there is some bit of disruption.
> Also, as far as I can tell, the adoption rate of Python 3.2 was very low.
> Python 3's story didn't become attractive until later.
>
>
> Raymond
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jelle.zijlstra%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Matěj Cepl 
On 2016-12-16, 19:24 GMT, Guido van Rossum wrote:
> I am beginning to think that `from __future__ import unicode_literals` does
> more harm than good. I don't recall exactly why we introduced it, but with
> the restoration of u"" literals in Python 3.3 we have a much better story
> for writing straddling code that is unicode-correct.

???

There has been absolute fanaticism about not changing anything 
in Python 2.* because of supposed stability of API, even in 
situations when I don’t think API was really in danger 
(http://bugs.python.org/issue19494).  And now you would remove 
a feature which zillions of lines of code depend on, or at least 
could depend on?

And yes, I do use it in my current porting efforts of M2Crypto 
to be py2/3k compatible.

I don’t understand.

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: [email protected]
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Never, never, never believe any war will be smooth and easy, or
that anyone who embarks on the strange voyage can measure the
tides and hurricanes he will encounter. The statesman who yields
to war fever must realise that once the signal is given, he is no
longer the master of policy but the slave of unforeseeable and
uncontrollable events.
-- Winston Churchill, 1930

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

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

2016-12-16 Thread Guido van Rossum 
On Fri, Dec 16, 2016 at 3:52 PM, Matěj Cepl  wrote:

> I don’t understand.
>

No need to get all bent out of shape. My proposal is to simply add a note
to the docs recommending against using this. I wouldn't change any code,
not even a silent deprecation warning. (Also, read the rest of the thread
to learn why this is not the best practice for writing Python 2/3
straddling code.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [RELEASE] Python 3.6.0rc2 is now available

2016-12-16 Thread Ned Deily 
On behalf of the Python development community and the Python 3.6 release
team, I would like to announce the availability of Python 3.6.0rc2. 3.6.0rc2
is the second release candidate for Python 3.6, the next major release of
Python.

Code for 3.6.0 is now frozen.  3.6.0rc2 is the same code base as the first
release candidate, 3.6.0rc1, with the addition of fixes for a couple of
critical problems and with some documentation additions and updates.
Assuming no further release critical problems are found prior to the 3.6.0
final release date, now planned for 2016-12-23, the 3.6.0 final release
will be the same code base as this 3.6.0rc2.  Maintenance releases for the
3.6 series will follow at regular intervals starting in the first quarter
of 2017.

Among the new major new features in Python 3.6 are:

* PEP 468 - Preserving the order of **kwargs in a function
* PEP 487 - Simpler customization of class creation
* PEP 495 - Local Time Disambiguation
* PEP 498 - Literal String Formatting
* PEP 506 - Adding A Secrets Module To The Standard Library
* PEP 509 - Add a private version to dict
* PEP 515 - Underscores in Numeric Literals
* PEP 519 - Adding a file system path protocol
* PEP 520 - Preserving Class Attribute Definition Order
* PEP 523 - Adding a frame evaluation API to CPython
* PEP 524 - Make os.urandom() blocking on Linux (during system startup)
* PEP 525 - Asynchronous Generators (provisional)
* PEP 526 - Syntax for Variable Annotations (provisional)
* PEP 528 - Change Windows console encoding to UTF-8
* PEP 529 - Change Windows filesystem encoding to UTF-8
* PEP 530 - Asynchronous Comprehensions

Please see "What’s New In Python 3.6" for more information:

https://docs.python.org/3.6/whatsnew/3.6.html

You can find Python 3.6.0rc2 here:

https://www.python.org/downloads/release/python-360rc2/

Note that 3.6.0rc2 is still a preview release and thus its use is not
recommended for production environments.

More information about the release schedule can be found here:

https://www.python.org/dev/peps/pep-0494/

--
  Ned Deily
  [email protected] -- []

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