Re: [Python-Dev] PEP 498: Naming

[Mike Miller]

Nice work!

So we're on the eve of pronouncement and though I've read several bring up the 
slightly-unfortunate naming of f-strings in the past, I've not seen recent 
discussion on the subject.  While the 498 implementation looks best, it still 
could be tweaked on the surface to use one of the other names or letters that 
had come up.  The original idea was to use f'' because it was thought that the 
feature would be locked to str.format, but that is no longer as true as it was 
originally.


To my knowledge there was i for interpolation, t for template, and e for 
expression suggested.  Any better ideas?


It's a good time to have this bikeshed discussion, because if the PEP is 
accepted news will get out and the name will be set in cement.  Previous drafts 
have made it out to hacker news and reddit, as the feature is exciting, so 
acceptance should as well.


-Mike


On 09/04/2015 06:45 PM, Eric V. Smith wrote:


I think it's now ready for Guido to pronounce on it.

___
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] Can't install Python 3.5rc3

[Steve Dower]

It thinks you have version 3.5.5339.0 installed, which IIRC was a test build I 
made for some tcl changes. It's probably listed under xPython - can you see it?

As I said at the time, they should be totally independent, but I guess not. 
Thanks for the heads up.

Top-posted from my Windows Phone

-Original Message-
From: "MRAB" 
Sent: ‎9/‎7/‎2015 20:41
To: "Python-Dev" 
Subject: [Python-Dev] Can't install Python 3.5rc3

I've been unable to install Python 3.5rc3.

It progresses to installing Tcl/tk, then reports that a newer version
of 3.5 is already installed, then it rolls back (slowly).

I don't know where it's finding this "newer version"; I've uninstalled
the previous releases of Python 3.5.

I'm on Windows 10.


Here's the contents of the log file:

[0A40:1CC8][2015-09-08T04:29:45]i001: Burn v3.10.0.1823, Windows v10.0 
(Build 10240: Service Pack 0), path: 
C:\Users\MRAB\Downloads\Python\python-3.5.0rc3.exe
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'ActionLikeInstalling' to value 'Installing'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'ActionLikeInstallation' to value 'Setup'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'ShortVersion' to value '3.5'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'ShortVersionNoDot' to value '35'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'InstallAllUsers' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'InstallLauncherAllUsers' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetDir' to value ''
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'DefaultAllUsersTargetDir' to value '[ProgramFilesFolder]Python 
[ShortVersion]'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetPlatform' to value 'x86'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'DefaultJustForMeTargetDir' to value 
'[LocalAppDataFolder]Programs\Python\Python[ShortVersionNoDot]-32'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'OptionalFeaturesRegistryKey' to value 
'Software\Python\PythonCore\[ShortVersion]-32\InstalledFeatures'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetDirRegistryKey' to value 
'Software\Python\PythonCore\[ShortVersion]-32\InstallPath'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'DefaultCustomTargetDir' to value ''
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'InstallAllUsersState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'InstallLauncherAllUsersState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'CustomInstallLauncherAllUsersState' to value 
'[InstallLauncherAllUsersState]'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'TargetDirState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'CustomBrowseButtonState' to value 'enabled'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_core' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_exe' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_dev' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_lib' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_test' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_doc' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_tools' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_tcltk' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_pip' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_launcher' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_symbols' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Include_debug' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'LauncherOnly' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'AssociateFiles' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'Shortcuts' to value '1'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'PrependPath' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'CompileAll' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing numeric variable 
'SimpleInstall' to value '0'
[0A40:1CC8][2015-09-08T04:29:45]i000: Initializing string variable 
'SimpleInstallDescription' to value ''
[0A40:1CC8][2015-09-08T04:29:45]i

Re: [Python-Dev] PEP 498: Naming

[Alexander Belopolsky]

On Tue, Sep 8, 2015 at 2:37 AM, Mike Miller 
wrote:

> To my knowledge there was i for interpolation, t for template, and e for
> expression suggested.  Any better ideas?


I believe someone suggested !"..." as well.   I still think f"..." notation
is the best as long as these elements are called "format strings" in the
documentation.  After all, we don't call a unicode string "u-string" or
bytes a "b-string".  Given enough imagination someone may find
not-safe-for-work associations in those abbreviations as well.
___
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] PEP 498: Naming

[Eric V. Smith]

On 09/08/2015 10:20 AM, Alexander Belopolsky wrote:
> 
> On Tue, Sep 8, 2015 at 2:37 AM, Mike Miller  > wrote:
> 
> To my knowledge there was i for interpolation, t for template, and e
> for expression suggested.  Any better ideas?
> 
> 
> I believe someone suggested !"..." as well.   I still think f"..."
> notation is the best as long as these elements are called "format
> strings" in the documentation.  After all, we don't call a unicode
> string "u-string" or bytes a "b-string".  Given enough imagination
> someone may find not-safe-for-work associations in those abbreviations
> as well.

Agreed. I discussed it with Guido offline, and we agreed on sticking
with f"" to tie in with str.format(), format(), __format__(), and format
strings.

Eric.

___
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] Yet another "A better story for multi-core Python" comment

[Gary Robinson]

Folks,

If it’s out of line in some way for me to make this comment on this list, let 
me know and I’ll stop! But I do feel strongly about one issue and think it’s 
worth mentioning, so here goes.

I read the "A better story for multi-core Python” with great interest because 
the GIL has actually been a major hindrance to me. I know that for many uses, 
it’s a non-issue. But it was for me.

My situation was that I had a huge (technically mutable, but unchanging) data 
structure which needed a lot of analysis. CPU time was a major factor — things 
took days to run. But even so, my time as a programmer was much more important 
than CPU time. I needed to prototype different algorithms very quickly. Even 
Cython would have slowed me down too much. Also, I had a lot of reason to want 
to make use of the many great statistical functions in SciPy, so Python was an 
excellent choice for me in that way. 

So, even though pure Python might not be the right choice for this program in a 
production environment, it was the right choice for me at the time. And, if I 
could have accessed as many cores as I wanted, it may have been good enough in 
production too. But my work was hampered by one thing:

There was a huge data structure that all the analysis needed to access. Using a 
database would have slowed things down too much. Ideally, I needed to access 
this same structure from many cores at once. On a Power8 system, for example, 
with its larger number of cores, performance may well have been good enough for 
production. In any case, my experimentation and prototyping would have gone 
more quickly with more cores.

But this data structure was simply too big. Replicating it in different 
processes used memory far too quickly and was the limiting factor on the number 
of cores I could use. (I could fork with the big data structure already in 
memory, but copy-on-write issues due to reference counting caused multiple 
copies to exist anyway.)

So, one thing I am hoping comes out of any effort in the “A better story” 
direction would be a way to share large data structures between processes. Two 
possible solutions:

1) More the reference counts away from data structures, so copy-on-write isn’t 
an issue. That sounds like a lot of work — I have no idea whether it’s 
practical. It has been mentioned in the “A better story” discussion, but I 
wanted to bring it up again in the context of my specific use-case. Also, it 
seems worth reiterating that even though copy-on-write forking is a Unix thing, 
the midipix project appears to bring it to Windows as well. (http://midipix.org)

2) Have a mode where a particular data structure is not reference counted or 
garbage collected. The programmer would be entirely responsible for manually 
calling del on the structure if he wants to free that memory. I would imagine 
this would be controversial because Python is currently designed in a very 
different way. However, I see no actual risk if one were to use an 
@manual_memory_management decorator or some technique like that to make it very 
clear that the programmer is taking responsibility. I.e., in general, 
information sharing between subinterpreters would occur through message 
passing. But there would be the option of the programmer taking responsibility 
of memory management for a particular structure. In my case, the amount of work 
required for this would have been approximately zero — once the structure was 
created, it was needed for the lifetime of the process. 

Under this second solution, there would be little need to actually remove the 
reference counts from the data structures — they just wouldn’t be accessed. 
Maybe it’s not a practical solution, if only because of the overhead of Python 
needing to check whether a given structure is manually managed or not. In that 
case, the first solution makes more sense.

In any case I thought this was worth mentioning,  because it has been a real 
problem for me, and I assume it has been a real problem for other people as 
well. If a solution is both possible and practical, that would be great.

Thank you for listening,
Gary


-- 

Gary Robinson
gary...@me.com
http://www.garyrobinson.net

___
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] Yet another "A better story for multi-core Python" comment

[Paul Moore]

On 8 September 2015 at 15:12, Gary Robinson  wrote:
> So, one thing I am hoping comes out of any effort in the “A better story” 
> direction would be a way to share large data structures between processes. 
> Two possible solutions:
>
> 1) More the reference counts away from data structures, so copy-on-write 
> isn’t an issue. That sounds like a lot of work — I have no idea whether it’s 
> practical. It has been mentioned in the “A better story” discussion, but I 
> wanted to bring it up again in the context of my specific use-case. Also, it 
> seems worth reiterating that even though copy-on-write forking is a Unix 
> thing, the midipix project appears to bring it to Windows as well. 
> (http://midipix.org)
>
> 2) Have a mode where a particular data structure is not reference counted or 
> garbage collected. The programmer would be entirely responsible for manually 
> calling del on the structure if he wants to free that memory. I would imagine 
> this would be controversial because Python is currently designed in a very 
> different way. However, I see no actual risk if one were to use an 
> @manual_memory_management decorator or some technique like that to make it 
> very clear that the programmer is taking responsibility. I.e., in general, 
> information sharing between subinterpreters would occur through message 
> passing. But there would be the option of the programmer taking 
> responsibility of memory management for a particular structure. In my case, 
> the amount of work required for this would have been approximately zero — 
> once the structure was created, it was needed for the lifetime of the process.

I guess a third possible solution, although it would probably have
meant developing something for yourself which would have hit the same
"programmer time is critical" issue that you noted originally, would
be to create a module that managed the data structure in shared
memory, and then use that to access the data from the multiple
processes. If your data structure is generic enough, you could make
such a module generally usable - or there may even be something
available already... I know you said that putting the data into a
database would be too slow, but how about an in-memory Sqlite database
(using shared memory so that there was only one copy for all
processes)?

Your suggestion (2), of having a non-refcounted data structure is
essentially this, doable as an extension module. The core data
structures all use refcounting, and that's unlikely to change, but
there's nothing to say that an extension module couldn't implement
fast data structures with objects allocated from a pool of
preallocated memory which is only freed as a complete block.

These suggestions are probably more suitable for python-list, though,
as (unlike your comment on non-refcounted core data structures) they
are things you can do in current versions of Python.

Paul
___
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] Choosing an official stance towards module deprecation in Python 3

[Brett Cannon]

There are two discussions going on in the issue tracker about deprecating
some modules and it has led to the inevitable discussion of Python 2/3
compatibility (I'm not even going to bother mentioning the issue #s as this
thread is not about the modules specifically but module deprecation in
general). Because I'm tired of rehashing the same discussion every time a
module deprecation comes up I would like to make an official decision that
we can follow any time we decide to deprecate a module.

The approaches to module deprecation I have seen are:
1. Nothing changes to the deprecation process; you deprecate a module and
remove it in one to two releases
2. Deprecate the module but with no plans for removal until Python 2.7
reaches its EOL (I have been calling this Python 4)
3. Document the deprecation but no actual code deprecation

I'm personally in the #2 camp. I want users to be fully aware that the
module in question is not being updated and possibly not even getting
non-critical bugfixes, but it's still there in Python 3 in order to make
sure that you can have code which straddles Python 2 & 3 more easily.

I don't like #1 because when the module exists in python 2.7 as it makes
transitioning from Python 2 a bit harder. Leaving code in the stdlib as
deprecated isn't going to kill us, especially if we make it clear the code
only exists for transitioning purposes and you very well may have to work
around any bugs you come across (and yes, this means changing my stance for
the formatter module's deprecation).

I don't like #3 because if you have an API memorized or you copied some
code you found online you very well may not realize a module is deprecated.
It's not difficult to silence a deprecation warning and you can make it so
that even if you use -Werror your deprecated module imports continue to
work without throwing an exception while all other deprecations do throw an
exception.

Whatever decision we come to I will update PEP 4 and then personally go
through the various deprecated modules in Python 3.6 and tweak them as
necessary to follow whatever policy we come up with.
___
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] Choosing an official stance towards module deprecation in Python 3

[Guido van Rossum]

#2 sounds fine to me.

On Tue, Sep 8, 2015 at 9:59 AM, Brett Cannon  wrote:

> There are two discussions going on in the issue tracker about deprecating
> some modules and it has led to the inevitable discussion of Python 2/3
> compatibility (I'm not even going to bother mentioning the issue #s as this
> thread is not about the modules specifically but module deprecation in
> general). Because I'm tired of rehashing the same discussion every time a
> module deprecation comes up I would like to make an official decision that
> we can follow any time we decide to deprecate a module.
>
> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module and
> remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)
> 3. Document the deprecation but no actual code deprecation
>
> I'm personally in the #2 camp. I want users to be fully aware that the
> module in question is not being updated and possibly not even getting
> non-critical bugfixes, but it's still there in Python 3 in order to make
> sure that you can have code which straddles Python 2 & 3 more easily.
>
> I don't like #1 because when the module exists in python 2.7 as it makes
> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
> deprecated isn't going to kill us, especially if we make it clear the code
> only exists for transitioning purposes and you very well may have to work
> around any bugs you come across (and yes, this means changing my stance for
> the formatter module's deprecation).
>
> I don't like #3 because if you have an API memorized or you copied some
> code you found online you very well may not realize a module is deprecated.
> It's not difficult to silence a deprecation warning and you can make it so
> that even if you use -Werror your deprecated module imports continue to
> work without throwing an exception while all other deprecations do throw an
> exception.
>
> Whatever decision we come to I will update PEP 4 and then personally go
> through the various deprecated modules in Python 3.6 and tweak them as
> necessary to follow whatever policy we come up with.
>
> ___
> 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/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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] Yet another "A better story for multi-core Python" comment

[Gary Robinson]

> I guess a third possible solution, although it would probably have
> meant developing something for yourself which would have hit the same
> "programmer time is critical" issue that you noted originally, would
> be to create a module that managed the data structure in shared
> memory, and then use that to access the data from the multiple
> processes.

I think you mean, write a non-python data structure in shared memory, such as 
writing it in C? If so, you’re right, I want to avoid the time overhead for 
writing something like that. Although I have used C data in shared-memory in 
the past when the data structure was simple enough. It’s not a foreign concept 
to me — it just would have been a real nuisance in this case.

An in-memory SQLLite database would have been too slow, at least if I used any 
kind of ORM. Without an ORM it still would have slowed things down while making 
for code that’s harder to read  and write. While I have used in-memory SQLite 
code at times, I’m not sure how much slowdown it would have engendered in this 
case. 

> Your suggestion (2), of having a non-refcounted data structure is
> essentially this, doable as an extension module. The core data
> structures all use refcounting, and that's unlikely to change, but
> there's nothing to say that an extension module couldn't implement
> fast data structures with objects allocated from a pool of
> preallocated memory which is only freed as a complete block.

Again, I think you’re talking about non-Python data structures, for instance C 
structures, which could be written to be “fast”? Again, I want to avoid writing 
that kind of code. Sure, for a production project where I had more programmer 
time, that would be a solution, but that wasn’t my situation. And, ideally, 
even if I had more time, I would greatly prefer not to have to spend it on that 
kind of code. I like Python because it saves me time and eliminates potential 
bugs that are associated with language like C but not with Python (primarily 
memory management related). To the extent that I have to write and debug 
external modules in C or C++, it doesn’t.

But, my view is: I shouldn’t be forced to even think about that kind of thing. 
Python should simply provide a solution. The fact that the reference counters 
are mixed in with the data structure, so that copy-on-write causes copies to be 
made of the data structure shouldn’t be something I should have to discover by 
trial and error, or by having deep knowledge of language and OS internals 
before I start a project, and then have to try to find a way to work around.

Obviously, Python, like any language, will always have limitations, and 
therefore it’s arguable that no one should say that any language “should” do 
anything it doesn’t do; if I don’t like it, I can use a more appropriate 
language. 

But these limitations aren’t obvious up-front. They make the language less 
predictable to people who don’t have a deep knowledge and just want to get 
something done and think Python (especially combined with things like SciPy) 
looks like a great choice to do them. And that confusion and uncertainty has to 
be bad for general language acceptance. I don’t see it as  “PR issue” — I see 
it as a practical issue having to do with the cost of knowledge acquisition. 
Indeed, I personally lost a lot of time because I didn’t understand them 
upfront!

Solving the problem I mention here would provide real benefits even with the 
current multiprocessing module. But it would also make the “A better story” 
subinterpreter idea a better solution than it would be without it. The 
subinterpreter multi-core solution is a major project — it seems like it would 
be a shame to create that solution and still have it not solve the problem 
discussed here.

Anyway, too much of this post is probably spent proseletyzing for my point of 
view. Members of python-dev can judge it as they think fit — I don’t have much 
more to say unless anyone has questions.

But if I’m missing something about the solutions mentioned by Paul, and they 
can be implemented in pure Python, I would be much appreciative if that could 
be explained!

Thanks,
Gary




-- 

Gary Robinson
gary...@me.com
http://www.garyrobinson.net

> On Sep 8, 2015, at 11:44 AM, Paul Moore  wrote:
> 
> On 8 September 2015 at 15:12, Gary Robinson  wrote:
>> So, one thing I am hoping comes out of any effort in the “A better story” 
>> direction would be a way to share large data structures between processes. 
>> Two possible solutions:
>> 
>> 1) More the reference counts away from data structures, so copy-on-write 
>> isn’t an issue. That sounds like a lot of work — I have no idea whether it’s 
>> practical. It has been mentioned in the “A better story” discussion, but I 
>> wanted to bring it up again in the context of my specific use-case. Also, it 
>> seems worth reiterating that even though copy-on-write forking is a Unix 
>> thing, the midipix project appears to bring it to Windows as 

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

[Donald Stufft]

On September 8, 2015 at 1:01:14 PM, Brett Cannon (bcan...@gmail.com) wrote:
> 
> The approaches to module deprecation I have seen are:
> 1. Nothing changes to the deprecation process; you deprecate a module and
> remove it in one to two releases
> 2. Deprecate the module but with no plans for removal until Python 2.7
> reaches its EOL (I have been calling this Python 4)
> 3. Document the deprecation but no actual code deprecation
> 

A riff on #1, is that it gets packaged up separately and released on PyPI, this
is basically what Django did when it removed django.contrib.comments from
Django. This kind of walks a line between 1 and 2 where the module is no longer
in the standard library, but if people are actually using those things, then
they are a fairly easy ``pip install`` away. This obviously only works for
"leaf" modules that don't have other parts of the standard library depending on
them, but #1 wouldn't work fo those anyways.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
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] What's New editing

[Laxmikant Chitare]

Hi Team Python,

It is really nice, motivating and encouraging to see people contribute to
community in spite of the work load. "Thank you" is just not enough to
appreciate your efforts. I have been programming in Python for quite some
time and I am loving it more as days pass by. I have been thinking of
contributing to the community but not sure how and where to start. Of
course my employer will never allow me do this as paid time, but I can take
out about an hour a day on my own. Can someone guide me how can I utilize
this time for the community?

Best regards,
Laxmikant

On Sun, Sep 6, 2015 at 2:52 AM, Yury Selivanov 
wrote:

>
> On 2015-09-05 2:23 PM, Guido van Rossum wrote:
>
>>
>> Awesome! We need more people with those skills!
>>
>> --Guido (on mobile)
>>
>>
> Great, we'll start today!
>
> Thanks,
> Yury
>
> ___
> 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/laxmikant.general%40gmail.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] What's New editing

[Chris Angelico]

On Wed, Sep 9, 2015 at 3:08 AM, Laxmikant Chitare
 wrote:
>
> It is really nice, motivating and encouraging to see people contribute to
> community in spite of the work load. "Thank you" is just not enough to
> appreciate your efforts. I have been programming in Python for quite some
> time and I am loving it more as days pass by. I have been thinking of
> contributing to the community but not sure how and where to start. Of course
> my employer will never allow me do this as paid time, but I can take out
> about an hour a day on my own. Can someone guide me how can I utilize this
> time for the community?

Pick up something that I keep telling myself I'll do more of, and
never seem to do a significant amount of: read through
http://bugs.python.org/ and confirm the unconfirmed, or check that
patches are working correctly, or add patches to things that
definitely need them. Even if you don't know C, there are plenty of
places where you could do that; large slabs of the standard library
are written in Python, and the docs are in a straight-forward markup
language, so docs patches basically just require knowledge of English.

ChrisA
___
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] Yet another "A better story for multi-core Python" comment

[R. David Murray]

On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson  wrote:
> 2) Have a mode where a particular data structure is not reference
> counted or garbage collected.

This sounds kind of like what Trent did in PyParallel (in a more generic
way).

--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] What's New editing

[Brett Cannon]

On Tue, 8 Sep 2015 at 10:11 Laxmikant Chitare 
wrote:

> Hi Team Python,
>
> It is really nice, motivating and encouraging to see people contribute to
> community in spite of the work load. "Thank you" is just not enough to
> appreciate your efforts. I have been programming in Python for quite some
> time and I am loving it more as days pass by. I have been thinking of
> contributing to the community but not sure how and where to start. Of
> course my employer will never allow me do this as paid time, but I can take
> out about an hour a day on my own. Can someone guide me how can I utilize
> this time for the community?
>

The easiest way is to read the devguide: https://docs.python.org/devguide/ .
It includes instructions on how you can help, instructions on how to join
the core-mentorship mailing list, etc.

-Brett


>
> Best regards,
> Laxmikant
>
> On Sun, Sep 6, 2015 at 2:52 AM, Yury Selivanov 
> wrote:
>
>>
>> On 2015-09-05 2:23 PM, Guido van Rossum wrote:
>>
>>>
>>> Awesome! We need more people with those skills!
>>>
>>> --Guido (on mobile)
>>>
>>>
>> Great, we'll start today!
>>
>> Thanks,
>> Yury
>>
>> ___
>> 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/laxmikant.general%40gmail.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/brett%40python.org
>
___
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] String Interpolation Best Practices

[Mike Miller]

Hi,

I'd like to collect thinking on best practices that we can use as a style guide 
for string interpolation.  Now that arbitrary expressions are very likely to be 
included, it is more important to set guidelines than it would otherwise be.


Below is a recent post with some good ideas (though it hopes to restrict 
expressions, which is not what we're discussing here, but rather creation of a 
style-guide for code-review a la PEP8).


Would anyone else like to contribute?

-Mike

Recent posts:

- On PEPs to augment PEP8:

https://mail.python.org/pipermail/python-dev/2015-September/141473.html

- On things to avoid in f-strings:

https://mail.python.org/pipermail/python-dev/2015-September/141451.html
(part included below)


On 09/05/2015 02:10 AM, haypo s (Victor Stinner) wrote:
> Would it be possible to specify a subset of the Python language
> allowed in f-string? For example, __import__ or lambda should not be
> used in a f-string. I'm not convinced that a loop or
> list/dict/set-comprehension is a good idea neither.
>
> I would prefer to keep as much code as possible *outside* f-string because:
> - text editor knows well how to color it
> - static analyzers know how to analyze it
> - it encourage developers to indent and comment their code correctly,
> whereas f-string has more restrictons on indentation (is it possible
> to indent and comment code inside a f-string?)
>
> For example, for me it's a common practice to write a complex
> list-comprehension on two lines for readability:
>
> newlist = [very_complex_expression(item)
>  for item in oldlist]
> # sorry, it's hard to indent correctly in a mail client, especially Gmail
>
> Well, I'm not convinced that we need a larger subset than what is
> allowed currently in str.format(), simple expressions like: obj.attr,
> obj[index], etc.
>
> I recall horrible examples in the previous mail threads showing how
> much complex code you can put inside f-string.
>
> Even the following example from the PEP seems too complex to me:
> print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
> valid_opts)}]", file=sys.stderr)
>
> Oh, first I read [...] as a list-comprehension :-p But it's part of
> the output string, not of the Python code...
>
> I prefer to build the second parameter outside the f-string:
> opts = '|'.join('--'+opt for opt in valid_opts)
> print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
>
___
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] PEP 498: Literal String Interpolation is ready for pronouncement

[Erik]

Hi.

I realise I'm coming late to the party on this, but I have a question 
about something I don't think the PEP makes clear.




When is the bytecode for the embedded expressions created?



Is it when the source code is parsed, or at runtime when the f-string is 
evaluated?


If the latter, then any process that works on bytecode (introspection 
tools, peep-hole optimisers etc) will need work.


I understand that colorising editors and analysis tools which operate at 
the source code level will need work, that's fair enough.



The PEP hints at things in this area in the "Specification", "Code 
equivalence" and "Expression evaluation" sections, and my guess is that 
it will (and should) happen during parsing, but I can't see where it 
comes right out and says it.


Thanks, E.
___
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] Choosing an official stance towards module deprecation in Python 3

[Brett Cannon]

On Tue, 8 Sep 2015 at 10:08 Donald Stufft  wrote:

> On September 8, 2015 at 1:01:14 PM, Brett Cannon (bcan...@gmail.com)
> wrote:
> >
> > The approaches to module deprecation I have seen are:
> > 1. Nothing changes to the deprecation process; you deprecate a module and
> > remove it in one to two releases
> > 2. Deprecate the module but with no plans for removal until Python 2.7
> > reaches its EOL (I have been calling this Python 4)
> > 3. Document the deprecation but no actual code deprecation
> >
>
> A riff on #1, is that it gets packaged up separately and released on PyPI,
> this
> is basically what Django did when it removed django.contrib.comments from
> Django. This kind of walks a line between 1 and 2 where the module is no
> longer
> in the standard library, but if people are actually using those things,
> then
> they are a fairly easy ``pip install`` away. This obviously only works for
> "leaf" modules that don't have other parts of the standard library
> depending on
> them, but #1 wouldn't work fo those anyways.
>

That is one possibility, but I notice that django.contrib.comments is still
getting updated. For deprecated modules they probably won't even get
bugfixes anymore so I wouldn't want to give the wrong impression the
modules are still being maintained. Plus we would have to figure out who is
in charge of the actual project on PyPI since there isn't a concept of
group ownership.
___
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] PEP 498: Literal String Interpolation is ready for pronouncement

[Guido van Rossum]

The byte code for the embedded expressions is all produced during the
regular byte code generation phase.

On Tue, Sep 8, 2015 at 3:30 AM, Erik  wrote:

> Hi.
>
> I realise I'm coming late to the party on this, but I have a question
> about something I don't think the PEP makes clear.
>
>
>
> When is the bytecode for the embedded expressions created?
>
>
>
> Is it when the source code is parsed, or at runtime when the f-string is
> evaluated?
>
> If the latter, then any process that works on bytecode (introspection
> tools, peep-hole optimisers etc) will need work.
>
> I understand that colorising editors and analysis tools which operate at
> the source code level will need work, that's fair enough.
>
>
> The PEP hints at things in this area in the "Specification", "Code
> equivalence" and "Expression evaluation" sections, and my guess is that it
> will (and should) happen during parsing, but I can't see where it comes
> right out and says it.
>
> Thanks, E.
>
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] String Interpolation Best Practices

[Guido van Rossum]

Sounds awfully premature. Style guides are typically updated in response to
the occurrence of bad practice in the wild, not in anticipation of such bad
practice. I would give the users of Python 3.6 some more credit.

On Tue, Sep 8, 2015 at 12:17 AM, Mike Miller 
wrote:

> Hi,
>
> I'd like to collect thinking on best practices that we can use as a style
> guide for string interpolation.  Now that arbitrary expressions are very
> likely to be included, it is more important to set guidelines than it would
> otherwise be.
>
> Below is a recent post with some good ideas (though it hopes to restrict
> expressions, which is not what we're discussing here, but rather creation
> of a style-guide for code-review a la PEP8).
>
> Would anyone else like to contribute?
>
> -Mike
>
> Recent posts:
>
> - On PEPs to augment PEP8:
>
>
> https://mail.python.org/pipermail/python-dev/2015-September/141473.html
>
> - On things to avoid in f-strings:
>
>
> https://mail.python.org/pipermail/python-dev/2015-September/141451.html
> (part included below)
>
>
> On 09/05/2015 02:10 AM, haypo s (Victor Stinner) wrote:
> > Would it be possible to specify a subset of the Python language
> > allowed in f-string? For example, __import__ or lambda should not be
> > used in a f-string. I'm not convinced that a loop or
> > list/dict/set-comprehension is a good idea neither.
> >
> > I would prefer to keep as much code as possible *outside* f-string
> because:
> > - text editor knows well how to color it
> > - static analyzers know how to analyze it
> > - it encourage developers to indent and comment their code correctly,
> > whereas f-string has more restrictons on indentation (is it possible
> > to indent and comment code inside a f-string?)
> >
> > For example, for me it's a common practice to write a complex
> > list-comprehension on two lines for readability:
> >
> > newlist = [very_complex_expression(item)
> >  for item in oldlist]
> > # sorry, it's hard to indent correctly in a mail client, especially Gmail
> >
> > Well, I'm not convinced that we need a larger subset than what is
> > allowed currently in str.format(), simple expressions like: obj.attr,
> > obj[index], etc.
> >
> > I recall horrible examples in the previous mail threads showing how
> > much complex code you can put inside f-string.
> >
> > Even the following example from the PEP seems too complex to me:
> > print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
> > valid_opts)}]", file=sys.stderr)
> >
> > Oh, first I read [...] as a list-comprehension :-p But it's part of
> > the output string, not of the Python code...
> >
> > I prefer to build the second parameter outside the f-string:
> > opts = '|'.join('--'+opt for opt in valid_opts)
> > print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
> >
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] PEP 498: Literal String Interpolation is ready for pronouncement

[Brett Cannon]

On Tue, 8 Sep 2015 at 10:26 Erik  wrote:

> Hi.
>
> I realise I'm coming late to the party on this, but I have a question
> about something I don't think the PEP makes clear.
>
>
>
> When is the bytecode for the embedded expressions created?


>
>
> Is it when the source code is parsed, or at runtime when the f-string is
> evaluated?
>

It's at compile time.


>
> If the latter, then any process that works on bytecode (introspection
> tools, peep-hole optimisers etc) will need work.
>
> I understand that colorising editors and analysis tools which operate at
> the source code level will need work, that's fair enough.
>
>
> The PEP hints at things in this area in the "Specification", "Code
> equivalence" and "Expression evaluation" sections, and my guess is that
> it will (and should) happen during parsing, but I can't see where it
> comes right out and says it.
>

It doesn't explicitly state it because it's inherent in the fact that it is
implemented in bytecode which is created at compile time for Python source
(typically when a module is imported, but can be when you call compile()).
___
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] Choosing an official stance towards module deprecation in Python 3

[Donald Stufft]

On September 8, 2015 at 1:29:58 PM, Brett Cannon (bcan...@gmail.com) wrote:
> 
> That is one possibility, but I notice that django.contrib.comments is still
> getting updated. For deprecated modules they probably won't even get
> bugfixes anymore so I wouldn't want to give the wrong impression the
> modules are still being maintained. Plus we would have to figure out who is
> in charge of the actual project on PyPI since there isn't a concept of
> group ownership.
> 

I don't really much care which way it is done, I was just throwing it out there
as a possibility. Though I think the first problem is solvable by clear
documentation. Actually in Django's case I think it was "Ok we've removed it,
if somebody wants to step up and maintain it they can, otherwise it's going to
wither and die on it's own", but my memory might be faulty. The second problem
is easier, you can add multiple people to a project, and "Organization/Group"
accounts will be something that gets implemented in Warehouse.


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


___
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] Yet another "A better story for multi-core Python" comment

[Sven R. Kunze]

On 08.09.2015 19:17, R. David Murray wrote:

On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson  wrote:

2) Have a mode where a particular data structure is not reference
counted or garbage collected.

This sounds kind of like what Trent did in PyParallel (in a more generic
way).


Yes, I can recall that from his talk as well.
___
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] Yet another "A better story for multi-core Python" comment

[Stephen J. Turnbull]

R. David Murray writes:
 > On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson  wrote:
 > > 2) Have a mode where a particular data structure is not reference
 > > counted or garbage collected.
 > 
 > This sounds kind of like what Trent did in PyParallel (in a more generic
 > way).

Except Gary has a large persistent data structure, and Trent's only
rule is "don't persist objects you want to operate on in parallel."
The similarity may be purely superficial, though.

@Gary: Justifying your request is unnecessary.  As far as I can see,
everybody acknowledges that "large shared data structure" + "multiple
cores" is something that Python doesn't do well enough in some sense.
It's just a hard problem, and the applications that really need it are
sufficiently specialized that we haven't been able to justify turning
the world upside down to serve them.

Trent seems to be on to something that requires only a bit of a tilt
;-), and despite the caveat above, I agree with David, check it out:

https://mail.python.org/pipermail/python-dev/2015-September/141485.html
___
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] Can't install Python 3.5rc3

[MRAB]

On 2015-09-08 14:22, Steve Dower wrote:
> It thinks you have version 3.5.5339.0 installed, which IIRC was a 
test build I made for some tcl changes. It's probably listed under 
xPython - can you see it?

>
> As I said at the time, they should be totally independent, but I 
guess not. Thanks for the heads up.

>
I purged the xPython bits, but it still wouldn't install.

I then purged the Python3.5dev... bits.

Success!

Rather a messy fix though...

>
> From: MRAB
> Sent: ‎9/‎7/‎2015 20:41
> To: Python-Dev
> Subject: [Python-Dev] Can't install Python 3.5rc3
>
> I've been unable to install Python 3.5rc3.
>
> It progresses to installing Tcl/tk, then reports that a newer version
> of 3.5 is already installed, then it rolls back (slowly).
>
> I don't know where it's finding this "newer version"; I've uninstalled
> the previous releases of Python 3.5.
>
> I'm on Windows 10.
>
>
> Here's the contents of the log file:

[snip]

___
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] String Interpolation Best Practices

[Guido van Rossum]

I was not asking for style rules. Maybe you're thinking of my encouraging
words regarding turning PEP 502 into an overview of the thinking that led
to PEP 498? Or maybe I wasn't clear enough that that's what I was
encouraging. :-)

On Tue, Sep 8, 2015 at 11:21 AM, Mike Miller 
wrote:

> Ok, I thought that's what you and others were asking for in previous
> threads.
>
> -Mike
>
>
>
> On 09/08/2015 10:32 AM, Guido van Rossum wrote:
>
>> Sounds awfully premature. Style guides are typically updated in response
>> to the
>>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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] Choosing an official stance towards module deprecation in Python 3

[Terry Reedy]

On 9/8/2015 12:59 PM, Brett Cannon wrote:

There are two discussions going on in the issue tracker about
deprecating some modules and it has led to the inevitable discussion of
Python 2/3 compatibility (I'm not even going to bother mentioning the
issue #s as this thread is not about the modules specifically but module
deprecation in general). Because I'm tired of rehashing the same
discussion every time a module deprecation comes up I would like to make
an official decision that we can follow any time we decide to deprecate
a module.


Would you consider the 'official decision' as applying to idlelib 
modules?  The issue here is not especially related to 2.7. PEP 434 
formalized the idea that idlelib is mostly private, but acknowledged 
that there might be unauthorized module uses here and there. The first 
example is removing idlelib.idlever, now unused by Idle itself (#21499).



The approaches to module deprecation I have seen are:
1. Nothing changes to the deprecation process; you deprecate a module
and remove it in one to two releases
2. Deprecate the module but with no plans for removal until Python 2.7
reaches its EOL (I have been calling this Python 4)


For either 1 or 2, the 2.7 code should get a py3 warning.


3. Document the deprecation but no actual code deprecation


Number 3 creates a discrepancy between code and doc.  This is normally 
considered a bug, and might be seen as such by someone reading both 
unless a comment were inserted into the code.



I'm personally in the #2 camp. I want users to be fully aware that the
module in question is not being updated and possibly not even getting
non-critical bugfixes, but it's still there in Python 3 in order to make
sure that you can have code which straddles Python 2 & 3 more easily.


There will be people who convert after 2020, but the final 3.x before 
removal will always be available.  I also see this as the best of 
imperfect choices.



I don't like #1 because when the module exists in python 2.7 as it makes
transitioning from Python 2 a bit harder. Leaving code in the stdlib as
deprecated isn't going to kill us, especially if we make it clear the
code only exists for transitioning purposes and you very well may have
to work around any bugs you come across (and yes, this means changing my
stance for the formatter module's deprecation).


Idlelib currently has about 6 module-naming conventions, and it was 
omitted from the 3.0 renaming. Even without an immediate mass PEP8 
rename (#24225), which would help Idle maintenance, new files from 
refactoring and ttk conversions will result in a large number of 
eventually unused old files. I would prefer to remove them before 2020.



I don't like #3 because if you have an API memorized or you copied some
code you found online you very well may not realize a module is
deprecated. It's not difficult to silence a deprecation warning and you
can make it so that even if you use -Werror your deprecated module
imports continue to work without throwing an exception while all other
deprecations do throw an exception.

Whatever decision we come to I will update PEP 4 and then personally go
through the various deprecated modules in Python 3.6 and tweak them as
necessary to follow whatever policy we come up with.


--
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] Choosing an official stance towards module deprecation in Python 3

[Brett Cannon]

On Tue, 8 Sep 2015 at 11:36 Terry Reedy  wrote:

> On 9/8/2015 12:59 PM, Brett Cannon wrote:
> > There are two discussions going on in the issue tracker about
> > deprecating some modules and it has led to the inevitable discussion of
> > Python 2/3 compatibility (I'm not even going to bother mentioning the
> > issue #s as this thread is not about the modules specifically but module
> > deprecation in general). Because I'm tired of rehashing the same
> > discussion every time a module deprecation comes up I would like to make
> > an official decision that we can follow any time we decide to deprecate
> > a module.
>
> Would you consider the 'official decision' as applying to idlelib
> modules?  The issue here is not especially related to 2.7. PEP 434
> formalized the idea that idlelib is mostly private, but acknowledged
> that there might be unauthorized module uses here and there. The first
> example is removing idlelib.idlever, now unused by Idle itself (#21499).
>

I consider IDLE so far outside the normal process of everything when it
comes to stdlib that it is exempt from everything so I don't care if you
take a module out completely.


>
> > The approaches to module deprecation I have seen are:
> > 1. Nothing changes to the deprecation process; you deprecate a module
> > and remove it in one to two releases
> > 2. Deprecate the module but with no plans for removal until Python 2.7
> > reaches its EOL (I have been calling this Python 4)
>
> For either 1 or 2, the 2.7 code should get a py3 warning.
>

I think that's redundant. People who need to run in both Python 2 and 3
will see the warning under Python 3. I view Py3kWarning for things that
would pass silently otherwise or have an odd error message under Python 3.
In this case the message will be clear in Python 3 and thus not a problem.


>
> > 3. Document the deprecation but no actual code deprecation
>
> Number 3 creates a discrepancy between code and doc.  This is normally
> considered a bug, and might be seen as such by someone reading both
> unless a comment were inserted into the code.
>
> > I'm personally in the #2 camp. I want users to be fully aware that the
> > module in question is not being updated and possibly not even getting
> > non-critical bugfixes, but it's still there in Python 3 in order to make
> > sure that you can have code which straddles Python 2 & 3 more easily.
>
> There will be people who convert after 2020, but the final 3.x before
> removal will always be available.  I also see this as the best of
> imperfect choices.
>

Yep. And people who want to see the modules to continue to exist can take
the modules and either vendor them or develop their own group of developers
around it and continue their maintenance outside of the stdlib.

-Brett


>
> > I don't like #1 because when the module exists in python 2.7 as it makes
> > transitioning from Python 2 a bit harder. Leaving code in the stdlib as
> > deprecated isn't going to kill us, especially if we make it clear the
> > code only exists for transitioning purposes and you very well may have
> > to work around any bugs you come across (and yes, this means changing my
> > stance for the formatter module's deprecation).
>
> Idlelib currently has about 6 module-naming conventions, and it was
> omitted from the 3.0 renaming. Even without an immediate mass PEP8
> rename (#24225), which would help Idle maintenance, new files from
> refactoring and ttk conversions will result in a large number of
> eventually unused old files. I would prefer to remove them before 2020.
>
> > I don't like #3 because if you have an API memorized or you copied some
> > code you found online you very well may not realize a module is
> > deprecated. It's not difficult to silence a deprecation warning and you
> > can make it so that even if you use -Werror your deprecated module
> > imports continue to work without throwing an exception while all other
> > deprecations do throw an exception.
> >
> > Whatever decision we come to I will update PEP 4 and then personally go
> > through the various deprecated modules in Python 3.6 and tweak them as
> > necessary to follow whatever policy we come up with.
>
> --
> 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/brett%40python.org
>
___
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] Choosing an official stance towards module deprecation in Python 3

[Barry Warsaw]

On Sep 08, 2015, at 10:02 AM, Guido van Rossum wrote:

>#2 sounds fine to me.

Agreed.
-Barry
___
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] String Interpolation Best Practices

[Mike Miller]

Ok, I thought that's what you and others were asking for in previous threads.

-Mike


On 09/08/2015 10:32 AM, Guido van Rossum wrote:

Sounds awfully premature. Style guides are typically updated in response to the

___
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] String Interpolation Best Practices

[Mike Miller]

Perhaps, here is my mention of it yesterday and response:

https://mail.python.org/pipermail/python-dev/2015-September/141487.html

Some have been asking for guidance on the subject though (see other links in 
this thread).  Maybe style-guide is the wrong terminology, but the idea wasn't 
intended to be insulting, haha.


I'll drop it and cut down PEP 502 a bit.  It is the easiest path for me, so no 
complaints.


-Mike


On 09/08/2015 11:25 AM, Guido van Rossum wrote:

I was not asking for style rules. Maybe you're thinking of my encouraging words
regarding turning PEP 502 into an overview of the thinking that led to PEP 498?
Or maybe I wasn't clear enough that that's what I was encouraging. :-)

On Tue, Sep 8, 2015 at 11:21 AM, Mike Miller mailto:python-id...@mgmiller.net>> wrote:

Ok, I thought that's what you and others were asking for in previous 
threads.

-Mike



On 09/08/2015 10:32 AM, Guido van Rossum wrote:

Sounds awfully premature. Style guides are typically updated in response
to the


___
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] Yet another "A better story for multi-core Python" comment

[Gary Robinson]

> 
> Trent seems to be on to something that requires only a bit of a tilt
> ;-), and despite the caveat above, I agree with David, check it out:

I emailed with Trent a couple years ago about this very topic. The biggest 
issue for me was that it was Windows-only, but it sounds like that restriction 
may be getting closer to possibly going away… (?)



-- 

Gary Robinson
gary...@me.com
http://www.garyrobinson.net

___
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] Yet another "A better story for multi-core Python" comment

[Joao S. O. Bueno]

Maybe you just have a job for Cap'n'proto?
https://capnproto.org/

On 8 September 2015 at 11:12, Gary Robinson  wrote:
> Folks,
>
> If it’s out of line in some way for me to make this comment on this list, let 
> me know and I’ll stop! But I do feel strongly about one issue and think it’s 
> worth mentioning, so here goes.
>
> I read the "A better story for multi-core Python” with great interest because 
> the GIL has actually been a major hindrance to me. I know that for many uses, 
> it’s a non-issue. But it was for me.
>
> My situation was that I had a huge (technically mutable, but unchanging) data 
> structure which needed a lot of analysis. CPU time was a major factor — 
> things took days to run. But even so, my time as a programmer was much more 
> important than CPU time. I needed to prototype different algorithms very 
> quickly. Even Cython would have slowed me down too much. Also, I had a lot of 
> reason to want to make use of the many great statistical functions in SciPy, 
> so Python was an excellent choice for me in that way.
>
> So, even though pure Python might not be the right choice for this program in 
> a production environment, it was the right choice for me at the time. And, if 
> I could have accessed as many cores as I wanted, it may have been good enough 
> in production too. But my work was hampered by one thing:
>
> There was a huge data structure that all the analysis needed to access. Using 
> a database would have slowed things down too much. Ideally, I needed to 
> access this same structure from many cores at once. On a Power8 system, for 
> example, with its larger number of cores, performance may well have been good 
> enough for production. In any case, my experimentation and prototyping would 
> have gone more quickly with more cores.
>
> But this data structure was simply too big. Replicating it in different 
> processes used memory far too quickly and was the limiting factor on the 
> number of cores I could use. (I could fork with the big data structure 
> already in memory, but copy-on-write issues due to reference counting caused 
> multiple copies to exist anyway.)
>
> So, one thing I am hoping comes out of any effort in the “A better story” 
> direction would be a way to share large data structures between processes. 
> Two possible solutions:
>
> 1) More the reference counts away from data structures, so copy-on-write 
> isn’t an issue. That sounds like a lot of work — I have no idea whether it’s 
> practical. It has been mentioned in the “A better story” discussion, but I 
> wanted to bring it up again in the context of my specific use-case. Also, it 
> seems worth reiterating that even though copy-on-write forking is a Unix 
> thing, the midipix project appears to bring it to Windows as well. 
> (http://midipix.org)
>
> 2) Have a mode where a particular data structure is not reference counted or 
> garbage collected. The programmer would be entirely responsible for manually 
> calling del on the structure if he wants to free that memory. I would imagine 
> this would be controversial because Python is currently designed in a very 
> different way. However, I see no actual risk if one were to use an 
> @manual_memory_management decorator or some technique like that to make it 
> very clear that the programmer is taking responsibility. I.e., in general, 
> information sharing between subinterpreters would occur through message 
> passing. But there would be the option of the programmer taking 
> responsibility of memory management for a particular structure. In my case, 
> the amount of work required for this would have been approximately zero — 
> once the structure was created, it was needed for the lifetime of the process.
>
> Under this second solution, there would be little need to actually remove the 
> reference counts from the data structures — they just wouldn’t be accessed. 
> Maybe it’s not a practical solution, if only because of the overhead of 
> Python needing to check whether a given structure is manually managed or not. 
> In that case, the first solution makes more sense.
>
> In any case I thought this was worth mentioning,  because it has been a real 
> problem for me, and I assume it has been a real problem for other people as 
> well. If a solution is both possible and practical, that would be great.
>
> Thank you for listening,
> Gary
>
>
> --
>
> Gary Robinson
> gary...@me.com
> http://www.garyrobinson.net
>
> ___
> 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/jsbueno%40python.org.br
___
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] Yet another "A better story for multi-core Python" comment

[cwillu]

On 8 September 2015 at 11:07, Gary Robinson  wrote:
>> I guess a third possible solution, although it would probably have
>> meant developing something for yourself which would have hit the same
>> "programmer time is critical" issue that you noted originally, would
>> be to create a module that managed the data structure in shared
>> memory, and then use that to access the data from the multiple
>> processes.
>
> I think you mean, write a non-python data structure in shared memory, such as 
> writing it in C? If so, you’re right, I want to avoid the time overhead for 
> writing something like that. Although I have used C data in shared-memory in 
> the past when the data structure was simple enough. It’s not a foreign 
> concept to me — it just would have been a real nuisance in this case.
>
> An in-memory SQLLite database would have been too slow, at least if I used 
> any kind of ORM. Without an ORM it still would have slowed things down while 
> making for code that’s harder to read  and write. While I have used in-memory 
> SQLite code at times, I’m not sure how much slowdown it would have engendered 
> in this case.
>
>> Your suggestion (2), of having a non-refcounted data structure is
>> essentially this, doable as an extension module. The core data
>> structures all use refcounting, and that's unlikely to change, but
>> there's nothing to say that an extension module couldn't implement
>> fast data structures with objects allocated from a pool of
>> preallocated memory which is only freed as a complete block.
>
> Again, I think you’re talking about non-Python data structures, for instance 
> C structures, which could be written to be “fast”? Again, I want to avoid 
> writing that kind of code. Sure, for a production project where I had more 
> programmer time, that would be a solution, but that wasn’t my situation. And, 
> ideally, even if I had more time, I would greatly prefer not to have to spend 
> it on that kind of code. I like Python because it saves me time and 
> eliminates potential bugs that are associated with language like C but not 
> with Python (primarily memory management related). To the extent that I have 
> to write and debug external modules in C or C++, it doesn’t.

I've used cffi to good effect to gain some of the benefits of the
"share a lump of memory" model.
___
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] PEP 498: Literal String Interpolation is ready for pronouncement

[Guido van Rossum]

I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who
contributed. A lot of thought and discussion went into this -- Eric himself
was against the idea when it first came up!

For those wondering about the fate of PEPs 501 and 502: 501 will be
deferred, and 502 will be turned into an informational PEP with background
information on string interpolation across the ages (so to speak :-).
Thanks to Nick Coghlan and Mike Miller for being good sports about it, and
for contributing valuable tire-kicking and devil's advocacy of PEP 498.

Now if only PEP 495 could be as easy... :-)

-- 
--Guido van Rossum (python.org/~guido)
___
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] PEP 498: Literal String Interpolation is ready for pronouncement

[Eric V. Smith]

On 9/8/2015 8:27 PM, Guido van Rossum wrote:
> I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who
> contributed. A lot of thought and discussion went into this -- Eric
> himself was against the idea when it first came up!

Thanks, Guido. In the next few days I'll update the implementation in
issue 24965 to reflect some changes in the PEP.

Thanks to Mike, Nick, Guido, and everyone else who helped improve the PEP.

Eric.

___
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] PEP 498: Literal String Interpolation is ready for pronouncement

[Mike Miller]

Yeah, can't wait to use it!

-Mike


On 09/08/2015 05:37 PM, Eric V. Smith wrote:

On 9/8/2015 8:27 PM, Guido van Rossum wrote:

I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who
contributed. A lot of thought and discussion went into this -- Eric
himself was against the idea when it first came up!


Thanks, Guido. In the next few days I'll update the implementation in
issue 24965 to reflect some changes in the PEP.

Thanks to Mike, Nick, Guido, and everyone else who helped improve the PEP.

Eric.


___
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] PEP 498: Literal String Interpolation is ready for pronouncement

[Mike Miller]

And thanks for making it a reality.  ;)

-Mike

On 09/08/2015 05:37 PM, Eric V. Smith wrote:
___
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] Yet another "A better story for multi-core Python" comment

[Terry Reedy]

On 9/8/2015 2:08 PM, Stephen J. Turnbull wrote:

R. David Murray writes:
  > On Tue, 08 Sep 2015 10:12:37 -0400, Gary Robinson  wrote:
  > > 2) Have a mode where a particular data structure is not reference
  > > counted or garbage collected.
  >
  > This sounds kind of like what Trent did in PyParallel (in a more generic
  > way).

Except Gary has a large persistent data structure, and Trent's only
rule is "don't persist objects you want to operate on in parallel."
The similarity may be purely superficial, though.


That rule, which includes not modifying persistent data, is only for the 
parallel threads. In his wikipedia search example, the main thread loads 
60 GB of data (and perhaps occasionally updates it) while multiple 
parallel threads, running of multiple cores, search the persistent data 
like busy little bees.


--
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] Choosing an official stance towards module deprecation in Python 3

[Nick Coghlan]

On 9 September 2015 at 04:56, Brett Cannon  wrote:
> On Tue, 8 Sep 2015 at 11:36 Terry Reedy  wrote:
>> > The approaches to module deprecation I have seen are:
>> > 1. Nothing changes to the deprecation process; you deprecate a module
>> > and remove it in one to two releases
>> > 2. Deprecate the module but with no plans for removal until Python 2.7
>> > reaches its EOL (I have been calling this Python 4)
>>
>> For either 1 or 2, the 2.7 code should get a py3 warning.
>
> I think that's redundant. People who need to run in both Python 2 and 3 will
> see the warning under Python 3. I view Py3kWarning for things that would
> pass silently otherwise or have an odd error message under Python 3. In this
> case the message will be clear in Python 3 and thus not a problem.

I was going to make the same suggestion as Terry, but you're right,
seeing the warning under 3.x will suffice in these cases.

So +1 for simple deprecation without removal until after 2.7 enters
security fix only mode.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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