Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 1 December 2014 01:17:02 CET, Ben Finney ben+pyt...@benfinney.id.au wrote: Donald Stufft don...@stufft.io writes: I have never heard of git losing history. In my experience talking with Git users about this problem, that depends on a very narrow definition of “losing history”. Git encourages re-writing, and thereby losing prior versions of, the history of a branch. The commit information remains, but the history of how they link together is lost. That is a loss of information, which is not the case in the absence of such history re-writing. Losing data is generally used in the sense that either the application or the filesystem accidentally deletes or overwrites data without the user's consent or knownledge. Rewriting and deleting (not losing) history in git is explicitly done by the user, encouraged or not. -- Markus ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes bytearray
On Sun, Aug 17, 2014 at 05:41:10PM -0400, Barry Warsaw wrote: I think the biggest API problem is that default iteration returns integers instead of bytes. That's a real pain. I agree, this behavior required some helper functions while porting Werkzeug to Python 3 AFAIK. I'm not sure .iterbytes() is the best name for spelling iteration over bytes instead of integers though. Given that we can't change __iter__(), I personally would perhaps prefer a simple .bytes property over which if you iterated you would receive bytes, e.g. I'd rather be for a .bytes() method, to match the .values(), and .keys() methods on dictionaries. -- Markus ___ 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] Criticism of execfile() removal in Python3
On Tue, Jun 10, 2014 at 05:23:12AM +0300, Paul Sokolovsky wrote: Hello, I was pleasantly surprised with the response to recent post about MicroPython implementation details (https://mail.python.org/pipermail/python-dev/2014-June/134718.html). I hope that discussion means that posts about alternative implementations are not unwelcome here, so I would like to bring up another (of many) issues we faced while implementing MicroPython. execfile() builtin function was removed in 3.0. This brings few problems: 1. It hampers interactive mode - instead of short and easy to type execfile(file.py) one needs to use exec(open(file.py).read()). I'm sure that's not going to bother a lot of people - after all, the easiest way to execute a Python file is to drop back to shell and restart python with file name, using all wonders of tab completion. But now imagine that Python interpreter runs on bare hardware, and its REPL is the only shell. That's exactly what we have with MicroPython's Cortex-M port. But it's not really MicroPython-specific, there's CPython port to baremetal either - http://www.pycorn.org/ . As far as i can see, minimizing the amount of characters to type was never a design goal of the Python language. And because that goal never mattered as much for the designers as it seems to do for you, the reason for it to get removed -- reducing the amount of builtins without reducing functionality -- was the only one left. 2. Ok, assuming that exec(open().read()) idiom is still a way to go, there's a problem - it requires to load entire file to memory. But there can be not enough memory. Consider 1Mb file with 900Kb comments (autogenerated, for example). execfile() could easily parse it, using small buffer. But exec() requires to slurp entire file into memory, and 1Mb is much more than heap sizes that we target. That is a valid concern, but i believe violating the language specification and adding your own execfile implementation (either as a builtin or in a new stdlib module) here is justified, even if it means you will have to modify your existing Python 3 code to use it -- i don't think the majority of software written in Python will be able to run under such memory constraints without major modifications anyway. Comments, suggestions? Just to set a productive direction, please kindly don't consider the problems above as MicroPython's. A new (not MicroPython-specific) stdlib module containing functions such as execfile could be considered. Not really for Python-2-compatibility, but for performance-critical situations. I am not sure if this is a good solution. Not at all. Even though it's separated from the builtins, i think it would still sacrifice the purity of the the language (by which i mean having a minimal composable API), because people are going to use it anyway. It reminds me of the situation in Python 2 where developers are trying to use cStringIO with a fallback to StringIO as a matter of principle, not because they actually need that kind of performance. Another, IMO better idea which shifts the problem to the MicroPython devs is to just detect code using exec(open(...).read()) and transparently rewrite it to something more memory-efficient. This is the idea i actually think is a good one. I very much liked how last discussion went: I was pointed that https://docs.python.org/3/reference/index.html is not really a CPython reference, it's a *Python* reference, and there were even motion to clarify in it some points which came out from MicroPython discussion. So, what about https://docs.python.org/3/library/index.html - is it CPython, or Python standard library specification? Assuming the latter, what we have is that, by removal of previously available feature, *Python* became less friendly for interactive usage and less scalable. Less friendly for interactive usage is a strong and vague statement. If you're going after the amount of characters required to type, yes, absolutely, but by that terms one could declare Bash and Perl to be superior languages. Look at it from a different perspective: There are fewer builtins to remember. Thanks, Paul mailto:pmis...@gmail.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/markus%40unterwaditzer.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] PEP 469: Restoring the iterkeys/values/items() methods
On Sat, Apr 19, 2014 at 02:25:53PM +1000, Steven D'Aprano wrote: In my experience, writing polyglot 2+3 code can be easily handled with a few helper functions, which is not the case with unicode string literals. (Non-polygot code of course can just use the methods directly.) I don't see this is a problem to be solved, or even much of a nuisance. Polyglot code is never going to be quite as straightforward or idiomic as non-polyglot code, and that's a good thing, as it reminds the reader that they are dealing with polyglot code. The problem i currently see is that most polyglot-projects are reimplementing the same helper functions (for dict access, literals wrapping etc), not depending on six because the authors don't feel it's worth the extra dependency, as they never need the full functionality of six. So how about including a subset of six' more popular functionality into the standard libraries of Python 2 and 3? I think it would solve the problem i described (i.e. remove boilerplate for polyglot code), while it would also avoid compromising the builtins of Python 3 (and keep polyglot code explicitly ugly) Also, that's why people demanded a Python 2.8... so that you don't have to pollute Python 3 instead. -- Markus ___ 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] Common subset of python 2 and python 3
On Wed, Jan 15, 2014 at 01:22:44PM +0100, Martin v. Löwis wrote: Am 12.01.14 18:39, schrieb Nachshon David Armon: I propose that this new version of python use the python 3 unicode model. As the version of python will be fully compatible with both python 2 and with python 3 but NOT necsesarily with all existing code in either. It is designed as a porting tool only. I don't think that it is possible to write an interpreter that is fully compatible for all it accepts. Would you think that the program print(repr(2**80).endswith(L)) is in the subset that should be supported by both Python 2 and Python 3? IMO Python 2 and 3 do have this part in common when you talk about valid syntax and available methods and functions, but not in terms of behavior. I think a new proposed Python version should simply crash on your example. I'm kind-of playing devil's advocate here because i agree with previous posters that such a Python version is unneccessary with tox and python2 -3 Notice that it prints True in Python 2 and False in Python 3. So if this common-version interpreter *rejects* the above program, which operation (**, repr, endswith) would you want to ban from subset? Warnings about using certain string methods on repr() might be a neat thing to add to python -3 or static analysis tools. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/markus%40unterwaditzer.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] PEP 423 : naming conventions and recipes related to packaging
In your first plone example you first use plone.app.content, but then present the directory structure of plone.app.command. Apart from that, the PEP seems legit to me, contentwise. I think some parts are clumsily formulated, but IMO rewriting these parts wouldn't even decrease the text's length or improve readability. -- Markus (from phone) Benoît Bryon ben...@marmelune.net wrote: Hi! Attached is a an updated proposal for PEP 423. You can also find it online at https://gist.github.com/benoitbryon/2815051 I am attending at EuroPython 2013 in Florence. Isn't it a great opportunity to get feedback and discuss about a PEP? I registered an open-space session and a lightning-talk today! Some notes about the update... The main point that was discussed in the previous proposal was the top-level namespace relates to code ownership rule. Here is a quote from Antoine Pitrou: Le 27/06/2012 12:50, Antoine Pitrou a écrit : On Wed, 27 Jun 2012 11:08:45 +0200 Benoît Bryonben...@marmelune.net wrote: Hi, Here is an informational PEP proposal: http://hg.python.org/peps/file/52767ab7e140/pep-0423.txt Could you review it for style, consistency and content? There is one Zen principle this PEP is missing: Flat is better than nested. This PEP seems to promote the practice of having a top-level namespace denote ownership. I think it should do the reverse: promote meaningful top-level packages (e.g. sphinx) as standard practice, and allow an exception for when a piece of software is part of a larger organizational body. So, the main change in the proposal I'm sending today is the removal of this ownership rule. It has been replaced by Use a single namespace (except special cases). Some additional changes have been performed, such as removal of some sections about opportunity or promote migrations. I also added a Rationale section where I pointed out some issues related to naming. The PEP has been marked as deferred because it was inactive and it is partly related to PEP 426. I left this deferred state. I am aware that some links in the PEP are broken... I will fix them later. My very first motivation is to get feedback about the big changes in the PEP. I wanted the update to be sent before EuroPython-2013's open-space session. I guess a detailed review would be nice anyway, for links, style, grammar... Also, I wonder whether the PEP could be shortened or not. Sometimes I cannot find straightforward words to explain things, so perhaps someone with better skills in english language could help. Or maybe some parts, such as the How to rename a project section, could be moved in other documents. Regards, Benoît ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/markus%40unterwaditzer.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python symbolizition
But why?
-- Markus (from phone)
Pynix Wang pynix.w...@gmail.com wrote:
1.lambda expression
c#
a.(x, y) = x == y
b.() = SomeMethod()
ruby:
- {|msg| puts msg}
python can use c# like and remove lambda keyword.
2.global variable
ruby
$glo_var
python can use $ or @ or another and remove global.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/markus%40unterwaditzer.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 443 Accepted
As somebody who missed the discussion about it and right now took a quick look at the PEP, i ask myself how subclasses are handled, as i don't see anything about it in the PEP, just support for ABCs. E.g if issubclass(Apple, Fruit) And i call a function which has registered an implementation for the Fruits type with an object of type Apple, is this implementation used? I assume so, but as said, i don't see it mentioned anywhere. -- Markus (from phone) Guido van Rossum gu...@python.org wrote: Łukasz, Congratulations! I've accepted PEP 443. I've already marked it as Accepted in the repo. I've also applied some very minor edits in order to make the text flow a little better in a few places. I think this is a great PEP -- it's simple, doesn't overreach, and you've managed the bikeshedding admirably. Thank you for your great contribution to Python! -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/markus%40unterwaditzer.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
