Re: [Python-Dev] subprocess.Popen and win32
On Python 3, you can use Unicode on all platforms. On UNIX, there is no
need to encode explicitly.
Victor
Le 20 avr. 2014 04:17, "David Aguilar" a écrit :
> Hi,
>
> I just joined python-dev because I found the need to add some code to
> paper over python3's subprocess API, and I'm wondering whether I'm
> missing something.
>
> On python2 and python3, the (only?) way to get utf-8 arguments to
> subprocess was to ensure that all unicode strings are encoded into
> bytes before subprocess sees them. This has worked for a long time
> (currently compatible across python2 and 3).
>
> On python3, this still works for normal platforms, but on windows we
> can't pass a list of byte strings. We have to pass a list of unicode
> strings.
>
> This means that the application code ends up needing to do this:
>
> https://github.com/git-cola/git-cola/commit/1109aeb4354c49931d9b0435d2b7cfdc2d5d6966
>
> basically,
>
> def start_command(cmd):
> if sys.platform == 'win32':
> # Python on windows always goes through list2cmdline() internally
> inside
> # of subprocess.py so we must provide unicode strings here
> otherwise
> # Python3 breaks when bytes are provided.
> cmd = [decode(c) for c in cmd]
> else:
> cmd = [encode(c) for c in cmd]
> return subprocess.Popen(cmd)
>
> That seems broken to me, so I wonder if this is a bug in the way
> python3 is handling Popen with list-of-bytestring on win32?
>
> I'm not a windows user, but I was able to install python3 under wine
> and the same traceback happens without the paper bag fix. This is what
> the traceback looks like; it dies in list2cmdline (which I am not
> calling directly, Popen does it under the covers):
>
> File "E:\Program Files
> (E)\git-cola\share\git-cola\lib\cola\core.py", line 109, in
> start_command
> universal_newlines=universal_newlines)
> File "C:\Python32\lib\subprocess.py", line 744, in __init__
> restore_signals, start_new_session)
> File "C:\Python32\lib\subprocess.py", line 936, in _execute_child
> args = list2cmdline(args)
> File "C:\Python32\lib\subprocess.py", line 564, in list2cmdline
> needquote = (" " in arg) or ("\t" in arg) or not arg
> TypeError: Type str doesn't support the buffer API
>
> This is an issue for folks that use python to write cross-platform
> code. The unix code paths expect list-of-bytes, but win32 only expects
> list-of-unicode, which pushes the burden onto the application
> programmer.
>
> It's my opinion that the win32 code path on python3 is the odd man
> out. If it allowed list-of-bytes like python2/win32 and python2+3/unix
> then this wouldn't be an issue.
>
> Is this an actual problem, or is it something that should be handled
> by application-level code as I've done?
>
> Thanks,
> --
> 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/victor.stinner%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] subprocess.Popen and win32
On Sat, 19 Apr 2014 19:02:42 -0700 David Aguilar wrote: > > On python3, this still works for normal platforms, but on windows we > can't pass a list of byte strings. We have to pass a list of unicode > strings. Windows native APIs are unicode-based. It is actually necessary to pass *unicode* strings, not byte strings, if you want your code to be correct in the face of non-ASCII characters. Under other platforms, when unicode strings are passed, Python will encode them using the platform's detected encoding. So, unless your platform is somehow misconfigured, passing unicode strings will also work correctly there. (note this is under Python 3) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On 20 April 2014 03:49, Steven D'Aprano wrote: > I don't believe that will happen, the line *will* be drawn somewhere, > before Python 3 dies a death of a thousand cuts. I think that the right > place to draw the line is *here*, not the next time, or the time after > that. I think that the decision should be made on technical reasons, not > so people feel that they are being listened to. I agree. I think that it's right that we should listen to users' frustrations with the (deliberately) backward incompatible changes. But listening does not imply not questioning. It's perfectly fair and reasonable to say "We understand that you feel there is an overhead here - we tried very hard to design Python 3 with future benefits in mind, and we assessed the costs as best we could given the data we had available. Could you please provide some quantitative data on how the loss of iterXXX affects you, with specific code details, so that we can review what you believe you have to do and consider whether you have missed an approach we were expecting projects to take, or whether your figures imply that we seriously underestimated the cost. We can then consider how best to address the implications of the information you provide." Ultimately, every time we add *any* sort of compatibility feature to Python 3 (Unicode literals, bytes interpolation, this) we are sending the message that we made a mistake in the design of Python 3. It's certainly possible that's the case (we didn't have a lot of hard data to go on) but I do think we should have a little more confidence in our judgement here. As Steven said, there are a *lot* of people happy with Python 3. They don't say much, precisely because they are happy - that's the point. Let's not fall foul of the mistake of only listening to people who complain. 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
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] PEP 469: Restoring the iterkeys/values/items() methods
On 20/04/2014 06:31, Ethan Furman wrote: Thank you for taking the time to write this up, Nick. However, I am -1 on it. One of the allures of Python 3 is the increase in simplicity and elegance. Restoring cruft does not help with that. Python 2 idioms that get restored to Python 3 must have real value: unicode literals, wire-protocol interpolations -- I don't feel that this comes any where close to meeting that bar. -- ~Ethan~ +1 for this summary which echoes my sentiments entirely. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.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] PEP 469: Restoring the iterkeys/values/items() methods
On 20 Apr 2014 08:14, "Markus Unterwaditzer" wrote: > > Also, that's why people demanded a Python 2.8... so that you don't have to > pollute Python 3 instead. It doesn't actually solve the problem in the library and framework cases though - most folks that are straddling 2/3 want to keep compatibility back to at least 2.6. That said, I think we've covered most of what can be discussed based on this initial iteration of the PEP. To advance the discussion further I need to do a new draft that: - quantifies the scale of the change to the dict API and covers ideas for mitigating that impact (like immediate deprecation and potentially even hiding them from dir(), or adding proper function and method deprecation support to pydoc) - quantifies the number of lines of Python 2 code potentially saved near term modification, or, if they have added Python 3 support already, the amount of work that *could* have been saved (I'm not a big enough fan of the proposal to do that work myself, though - if the folks requesting the change aren't sufficiently interested to consider it worth their while to quantify the direct benefits even deprecated methods could have saved them, I consider that a data point in its own right) - explicitly covers all the different ways methods that produce iterators can be operated on, and how those need to be handled differently when migrating to the common subset of Python 2 & 3 rather than directly to 3. Regards, Nick. > > -- 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/ncoghlan%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] PEP 469: Restoring the iterkeys/values/items() methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/2014 07:37 AM, Paul Moore wrote: > Ultimately, every time we add *any* sort of compatibility feature to > Python 3 (Unicode literals, bytes interpolation, this) we are sending > the message that we made a mistake in the design of Python 3. It's > certainly possible that's the case (we didn't have a lot of hard data > to go on) but I do think we should have a little more confidence in > our judgement here. We clearly made mistakes, especially in how we thought migration would occur: nobody expected that we would see straddling / compatible subset as the dominant porting strategy. Re-adding features to make the strategy that works less painful is just acknowledging that fact. Mark such features as BBB-only / deprecated-but-never-to-be-removed, and move on: "practicality beats purity". Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNT4gcACgkQ+gerLs4ltQ4a3wCfcKZWldlrPzNn6byYJrCxm1XG ttUAniKTQ6ma0n7XNIMf0lP4A1zexT6j =AkQ+ -END PGP SIGNATURE- ___ 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 Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote: > Does one ever use iteritems() et al without first invoking iter() on > it? I can't speak for others, but I never invoke iteritems *with* iter(). What would be the point? iteritems is documented as returning an interator. # never this for key, value in iter(mydict.iteritems()): ... # but this for key, value in mydict.iteritems(): ... > I.e. is it important that it is an iterator, rather than an > iterable? I think we could easily relax that requirement in the pep > and solve 99% of the use cases. And the other 1% of cases would be a land-mine waiting to blow the user's code up. Would it actually solve 99% of the use cases? Or only 90%? Or 50%? How do you know? In Python 2.7 iteritems() etc is documented as returning an iterator. That's a promise of the language, and people will rely on it. But they won't be able to rely on that promise in polygot 2+3 code -- exactly the use-case this PEP is trying to satisfy -- because the promise to return an iterator will be broken in 3. It would be actively misleading, since Python 3's iteritems() would return a view, not an iter, and it would fail at solving the backwards compatibility issue since views and iterators are not interchangeable except for the most basic use of iteration. ___ 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
> -Original Message- > From: Python-Dev [mailto:python-dev- > bounces+kristjan=ccpgames@python.org] On Behalf Of Eric Snow > Sent: 19. apríl 2014 23:15 > To: Barry Warsaw > Cc: Python-Dev > Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() > methods > > I agree. I've been trying to get rid of iter*() when porting because > > most of the time, there is no significant memory savings to be achieved > anyway. > While I also have the gut feeling that we have been placing too much value in the memory savings of iteritems() vs iter(), the approach of just using "iter()" has the problem that it is semantically different. Compatible source code would have to use "list(mydict.items())" to have the same meaning in 2 and 3. And then we are starting to feel pain again. K ___ 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
Well, "for i in x" and other iteration constructs already call "iter ()" on their iterable. That's the point. Unless you want to manually iterate using "next ()" then the distinction between an iterable and an iterator is academic. Sent from the æther. Original message From: Steven D'Aprano Date:20/04/2014 17:05 (GMT+00:00) To: python-dev@python.org Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote: > Does one ever use iteritems() et al without first invoking iter() on > it? I can't speak for others, but I never invoke iteritems *with* iter(). What would be the point? iteritems is documented as returning an interator. # never this for key, value in iter(mydict.iteritems()): ... # but this for key, value in mydict.iteritems(): ... > I.e. is it important that it is an iterator, rather than an > iterable? I think we could easily relax that requirement in the pep > and solve 99% of the use cases. And the other 1% of cases would be a land-mine waiting to blow the user's code up. Would it actually solve 99% of the use cases? Or only 90%? Or 50%? How do you know? In Python 2.7 iteritems() etc is documented as returning an iterator. That's a promise of the language, and people will rely on it. But they won't be able to rely on that promise in polygot 2+3 code -- exactly the use-case this PEP is trying to satisfy -- because the promise to return an iterator will be broken in 3. It would be actively misleading, since Python 3's iteritems() would return a view, not an iter, and it would fail at solving the backwards compatibility issue since views and iterators are not interchangeable except for the most basic use of iteration. ___ 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/kristjan%40ccpgames.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] PEP 469: Restoring the iterkeys/values/items() methods
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Steven
> On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote:
> > Wouldn't "iterkeys" simply be an alias for "keys" and so on?
> > I'm +1 on that.
>
> No.
>
> [steve@ando ~]$ python2.7 -c "it = {}.iterkeys(); print it is iter(it)"
> True
> [steve@ando ~]$ python3.3 -c "it = {}.keys(); print(it is iter(it))"
> False
>
Does one ever use iteritems() et al without first invoking iter() on it? I.e.
is it important that it is an iterator, rather than an iterable?
I think we could easily relax that requirement in the pep and solve 99% of the
use cases.
K
___
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 Sun, Apr 20, 2014 at 12:27 PM, Kristján Valur Jónsson wrote: > Well, "for i in x" and other iteration constructs already call "iter ()" on > their iterable. That's the point. Unless you want to manually iterate using > "next ()" then the distinction between an iterable and an iterator is > academic. Or unless you iterate over the same thing multiple times, which can happen. P.S.: If Python had intended to support 2.x/3.x polyglots in the first place, would iteritems etc. have been removed? My feeling is "no", in which case they should be re-added, since this is the main supported porting mechanism going forward. -- Devin > Original message > From: Steven D'Aprano > Date:20/04/2014 17:05 (GMT+00:00) > To: python-dev@python.org > Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() > methods > > On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote: > >> Does one ever use iteritems() et al without first invoking iter() on >> it? > > I can't speak for others, but I never invoke iteritems *with* iter(). > What would be the point? iteritems is documented as returning an > interator. > > # never this > for key, value in iter(mydict.iteritems()): ... > > # but this > for key, value in mydict.iteritems(): ... > > >> I.e. is it important that it is an iterator, rather than an >> iterable? I think we could easily relax that requirement in the pep >> and solve 99% of the use cases. > > And the other 1% of cases would be a land-mine waiting to blow the > user's code up. > > Would it actually solve 99% of the use cases? Or only 90%? Or 50%? How > do you know? > > In Python 2.7 iteritems() etc is documented as returning an iterator. > That's a promise of the language, and people will rely on it. But they > won't be able to rely on that promise in polygot 2+3 code -- exactly the > use-case this PEP is trying to satisfy -- because the promise to return > an iterator will be broken in 3. > > It would be actively misleading, since Python 3's iteritems() would > return a view, not an iter, and it would fail at solving the backwards > compatibility issue since views and iterators are not interchangeable > except for the most basic use of iteration. > > ___ > 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/kristjan%40ccpgames.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/jeanpierreda%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
[Python-Dev] Python usability study (Was: Language Summit notes)
On Thu, Apr 10, 2014 at 2:24 PM, Kushal Das wrote: > Glyph wants a PSF fund to a usability study on Python. There were a > few other suggestion on PSF support for tooling development. +2 on initiative -- anatoly t. ___ 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] subprocess.Popen and win32
On Sun, Apr 20, 2014 at 2:42 AM, Antoine Pitrou wrote: > On Sat, 19 Apr 2014 19:02:42 -0700 > David Aguilar wrote: >> >> On python3, this still works for normal platforms, but on windows we >> can't pass a list of byte strings. We have to pass a list of unicode >> strings. > > Windows native APIs are unicode-based. It is actually necessary to pass > *unicode* strings, not byte strings, if you want your code to be > correct in the face of non-ASCII characters. > > Under other platforms, when unicode strings are passed, Python will > encode them using the platform's detected encoding. So, unless your > platform is somehow misconfigured, passing unicode strings will also > work correctly there. > > (note this is under Python 3) Curious.. what if I don't want the default encoding? On UNIX, I can control what encoding is used because I can encoding unicode strings into bytes and the programmer is in full control. I was mainly surprised that this is valid code on unix, but not windows, and which seems like a portability concern. If I use unicode strings that means I'm beholden to the default encoding. I do agree that utf-8 (python3) is the only sane encoding (for filesystems, etc) which is why it's just a curious question, and for my use case, the default encoding on python3 (utf-8) is good enough. The projects I work on (including at work, where there is a huge python2 code base) are python2+3 compatible by necessity, so it seems like the best solution would be to check the python version, rather than the platform, before deciding whether or not to encode or decode inputs before calling into subprocess. That works for me :-) Thanks for the explanation. ciao, -- 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] this is what happens if you freeze all the modules required for startup
On 18.04.2014 23:03, Ezio Melotti wrote: > Hi, > > On Thu, Apr 17, 2014 at 9:09 PM, Brett Cannon wrote: >> >> >> On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić >> wrote: >>> >>>Hi. >>> >>> On 14.4.2014. 23:51, Brett Cannon wrote: Now the question is whether the maintenance cost of having to rebuild Python for a select number of stdlib modules is enough to warrant putting in the effort to make this work. >>> >>>I would really love to have better startup times in production, but I >>> would also really hate to lose the ability to hack around in stdlib >>> sources during development just to get better startup performance. >>> >>>In general, what I really like about using Python for software >>> development is the ability to open any stdlib file and easily go poking >>> around using stuff like 'import pdb;pdb.set_trace()' or simple print >>> statements. Researching mysterious behaviour is generally much much >>> MUCH! easier (read: takes less hours/days/weeks) if it ends up leading >>> into a stdlib Python module than if it takes you down into the bowels of >>> some C module (think zipimport.c *grin*). Not to mention the effect that >>> being able to quickly resolve a mystery by hacking on some Python >>> internals leaves you feeling very satisfied, while having to entrench >>> yourself in those internals for a long time just to find out you've made >>> something foolish on your end leaves you feeling exhausted at best. >> >> >> Freezing modules does not affect the ability to use gdb. And as long as you >> set the appropriate __file__ values then tracebacks will contain even the >> file line and location. >> > > Will the tracebacks only contain the line number or the line of code too? > > I've seen tracebacks involving importlib,_bootstrap that didn't > include the code, and I'm wondering if we will get something similar > for all the other modules you are freezing: > > Traceback (most recent call last): > File "/tmp/foo.py", line 7, in > import email > File "", line 1561, in _find_and_load > File "", line 1519, in _find_and_load_unlocked > File "", line 1473, in _find_module > File "", line 1308, in find_module > File "", line 1284, in _get_loader > File "", line 1273, in _path_importer_cache > File "", line 1254, in _path_hooks > TypeError: 'NoneType' object is not iterable Yes, this is what you get for frozen modules. If you'd like to play around with a frozen stdlib this, you can have a look at PyRun (http://pyrun.org), which does this for Python 2 and will hopefully work for Python 3.4 soonish too. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Fw: fail to fetch python-dev for raspian with details of error message
Dear sir, I am working on WebIOPi where library of python-dev is needed, so I use "sudo apt-get install python-dev" to install it. Then returned message of: fail to fetch http://mirrordirector.raspbian.org/raspbian/ wheezy.. details of error message: Found Python 2.7.3rc2... Trying to install python-dev using apt-get Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libexpat1-dev libssl-dev libssl-doc python2.7-dev The following NEW packages will be installed: libexpat1-dev libssl-dev libssl-doc python-dev python2.7-dev 0 upgraded, 5 newly installed, 0 to remove and 3 not upgraded. Need to get 31.3 MB of archives. After this operation, 42.2 MB of additional disk space will be used. Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main python2.7-dev armhf 2.7.3~rc2-2.1 404 Not Found Get:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main python-dev all 2.7.3~rc2-1 [912 B] Get:2 http://mirrordirector.raspbian.org/raspbian/ wheezy/main libexpat1-dev armhf 2.1.0-1 [210 kB] Get:3 http://mirrordirector.raspbian.org/raspbian/ wheezy/main libssl-dev armhf 1.0.1c-4+rpi1 [1,494 kB] Get:4 http://mirrordirector.raspbian.org/raspbian/ wheezy/main libssl-doc all 1.0.1c-4+rpi1 [1,204 kB] Fetched 2,909 kB in 21s (136 kB/s) Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/p/python2.7/python2.7-dev_2.7.3~rc2-2.1_armhf.deb 404 Not Found E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Cannot install for Python 2.7.3rc2 : missing development headers Found Python 3.2.3... Trying to install python3-dev using apt-get Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libexpat1-dev libpython3.2 libssl-dev libssl-doc python3.2-dev The following NEW packages will be installed: libexpat1-dev libpython3.2 libssl-dev libssl-doc python3-dev python3.2-dev 0 upgraded, 6 newly installed, 0 to remove and 3 not upgraded. Need to get 31.0 MB/33.9 MB of archives. After this operation, 46.8 MB of additional disk space will be used. Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main libpython3.2 armhf 3.2.3-2 404 Not Found Err http://mirrordirector.raspbian.org/raspbian/ wheezy/main python3.2-dev armhf 3.2.3-2 404 Not Found Get:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main python3-dev all 3.2.3-5 [1,060 B] Fetched 1,060 B in 0s (5,711 B/s) Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/p/python3.2/libpython3.2_3.2.3-2_armhf.deb 404 Not Found Failed to fetch http://mirrordirector.raspbian.org/raspbian/pool/main/p/python3.2/python3.2-dev_3.2.3-2_armhf.deb 404 Not Found E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Cannot install for Python 3.2.3 : missing development headers ERROR: WebIOPi cannot be installed - please check errors above Would you please to advise a solution. Many many thanks! Ken TIML MOM Limited 交通基建管理合約有限公司 P Please think of the environment before printing this email Disclaimer: This e-mail message (together with any attachments) is confidential to the addressee and may also be privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. Please also notify the sender immediately by return e-mail and delete it from your system. Internet communications cannot be guaranteed to be secure or error-free. The sender and the entity through which this message is sent therefore ___ 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 Sun, Apr 20, 2014 at 07:27:08PM +, Kristján Valur Jónsson wrote: > Well, "for i in x" and other iteration constructs already call "iter > ()" on their iterable. That's the point. Unless you want to manually > iterate using "next ()" then the distinction between an iterable and > an iterator is academic. Do you think that for loops are the only way that iteritems and friends get used? You can't know that. I know from my own code that it isn't true. Iterators are first class objects like any other object, and they get put into tuples, passed around as arguments to functions, stored in variables, and so on. They get tested to be iterators, e.g.: assert the_items is iter(the_items) and, yes, sometimes people call next() on them directly. There is a reason that viewitems() etc. were added to Python 2.7 rather than just changing iteritems() to return a view. It would break backward compatibility, and break people's code. How much code? I don't know, but *any* breakage defeats the purpose of this suggestion. The whole point of this PEP is for the iter* methods to work the same way in Python 2 and Python 3, not "nearly the same, sorry if it breaks your code". If we wanted "nearly the same", we already have that: dict.items() in Python 2 and 3 is already nearly the same, they are both iterable. Nearly the same is not good enough. If this is a cunning plan to make Nick's suggestion sound better by suggesting an even worse alternative, it's working :-) -- Steven ___ 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] Fw: fail to fetch python-dev for raspian with details of error message
On 4/20/2014 8:25 PM, Ken Chan wrote: Please send this instead to python-list, where you might find other raspian users. Pydev is for development of future version of python, not use of current versions. -- 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] PEP 469: Restoring the iterkeys/values/items() methods
On 20Apr2014 14:32, Mark Lawrence wrote: On 20/04/2014 06:31, Ethan Furman wrote: Thank you for taking the time to write this up, Nick. However, I am -1 on it. One of the allures of Python 3 is the increase in simplicity and elegance. Restoring cruft does not help with that. Python 2 idioms that get restored to Python 3 must have real value: unicode literals, wire-protocol interpolations -- I don't feel that this comes any where close to meeting that bar. ~Ethan~ +1 for this summary which echoes my sentiments entirely. Me too. I'm against iteritems and friends coming back. I've been burned in the past with the burden of writing a mapping class with the many methods such a thing must support; both items() and iteritems() and so forth. For the example I have in mind I eventually abandoned the objective of being a full mapping and am going back to just a few methods to support easy element access such as __getitem__ and __contains__. I have a small python module of my own to aid my python 2+3 efforts, and am of the opinion that it is better to add iteritems elper functions to a popular module like six than to left the noise back into the python 3 mapping interface. Cheers, Cameron Simpson ___ 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 Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson wrote: > On 20Apr2014 14:32, Mark Lawrence wrote: >> >> On 20/04/2014 06:31, Ethan Furman wrote: >>> >>> Thank you for taking the time to write this up, Nick. >>> >>> However, I am -1 on it. One of the allures of Python 3 is the increase >>> in simplicity and elegance. Restoring cruft does not help with that. >>> Python 2 idioms that get restored to Python 3 must have real value: >>> unicode literals, wire-protocol interpolations -- I don't feel that this >>> comes any where close to meeting that bar. >>> ~Ethan~ >> >> >> +1 for this summary which echoes my sentiments entirely. > > > Me too. I'm against iteritems and friends coming back. > > I've been burned in the past with the burden of writing a mapping class with > the many methods such a thing must support; both items() and iteritems() and > so forth. For the example I have in mind I eventually abandoned the > objective of being a full mapping and am going back to just a few methods to > support easy element access such as __getitem__ and __contains__. As far as I know, all you have to implement yourself, to support the dict-like interface, are: - __getitem__ - __setitem__ - __delitem__ - __iter__ - __len__ MutableMapping can implement the rest. This wouldn't change with the re-addition of the iter* methods. You really have to use MutableMapping now that keys/items/values are complicated objects: it's much harder to implement dict-like objects from scratch in 3.x than 2.x. -- Devin ___ 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 20Apr2014 20:12, Devin Jeanpierre wrote: On Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson wrote: Me too. I'm against iteritems and friends coming back. I've been burned in the past with the burden of writing a mapping class with the many methods such a thing must support; both items() and iteritems() and so forth. [...] As far as I know, all you have to implement yourself, to support the dict-like interface, are: - __getitem__ - __setitem__ - __delitem__ - __iter__ - __len__ MutableMapping can implement the rest. This wouldn't change with the re-addition of the iter* methods. You really have to use MutableMapping now that keys/items/values are complicated objects: it's much harder to implement dict-like objects from scratch in 3.x than 2.x. Fair point. Thank you, Cameron Simpson Draw little boxes with arrows. It helps. - Michael J. Eager ___ 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
Tres Seaver writes: > Re-adding features to make the strategy that works less painful is > just acknowledging that fact. Whether the strategy that works was anticipated is irrelevant, and the fact that pain *would* be involved was acknowledged all the way back to the days when "Python 3000" was still a python-dev in joke rather than something that downstream needed to think about for the future. The question is "how much pain", and I'm sorry, but I don't see that the .iterthingee methods involve so much pain. The request for explanation and quantification seems eminently reasonable to me. > Mark such features as BBB-only / deprecated-but-never-to-be-removed, and > move on: "practicality beats purity". Since your statement is a first-order sentence, it's implicitly universally quantified. "All" is a *lot* of cruft, Tres! Where do *you* propose finally saying "the cruft stops here"? Also, whatever cruft ends up being included *will* be propagated forward in code that does *not* need it, including new code. Most "new" code is plagiarized to some degree, and people plagiarize not with a critic's eye, but with an eye to "does the API have the semantics I need when it calls that code?" Nor do they enable deprecation notices, or read documentation if the reused code Just Works ___ 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 19 April 2014 12:17, Nick Coghlan wrote: > That may help clarify the tricky warts and edge cases that can arise when > moving from the current relatively straightforward and consistent method > based approach to a more complicated combination of dedicated syntax and > helper functions. OK, I've now updated the PEP to better described the *problem* (rather than skipping ahead to proposing a specific solution - exactly what I was asking people *not* to do at the language summit!), and I now think this is better handled by tweaking the strategies people use when writing or converting to hybrid code, rather than by making any changes to Python 3. The use of more appropriate helper functions should actually make the hybrid code *cleaner* than it would be with any Python 3 API restorations. Accordingly, the PEP itself is now marked as Withdrawn, but it also goes into a lot more detail on the Python 2 mapping iteration APIs, how 2to3 translates them to Python 3, and how I now suggest people translate them to the common subset of Python 2 and 3. Full text of the revised PEP is below, and it has also been updated at http://www.python.org/dev/peps/pep-0469/ Cheers, Nick. = PEP: 469 Title: Migration of dict iteration code to Python 3 Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan Status: Withdrawn Type: Standards Track Content-Type: text/x-rst Created: 2014-04-18 Python-Version: 3.5 Post-History: 2014-04-18, 2014-04-21 Abstract For Python 3, PEP 3106 changed the design of the ``dict`` builtin and the mapping API in general to replace the separate list based and iterator based APIs in Python 2 with a merged, memory efficient set and multiset view based API. This new style of dict iteration was also added to the Python 2.7 ``dict`` type as a new set of iteration methods. This means that there are now 3 different kinds of dict iteration that may need to be migrated to Python 3 when an application makes the transition: * Lists as mutable snapshots: ``d.items()`` -> ``list(d.items())`` * Iterator objects: ``d.iteritems()`` -> ``iter(d.items())`` * Set based dynamic views: ``d.viewitems()`` -> ``d.items()`` There is currently no widely agreed best practice on how to reliably convert all Python 2 dict iteration code to the common subset of Python 2 and 3, especially when test coverage of the ported code is limited. This PEP reviews the various ways the Python 2 iteration APIs may be accessed, and looks at the available options for migrating that code to Python 3 by way of the common subset of Python 2.6+ and Python 3.0+. The PEP also considers the question of whether or not there are any additions that may be worth making to Python 3.5 that may ease the transition process for application code that doesn't need to worry about supporting earlier versions when eventually making the leap to Python 3. PEP Withdrawal == In writing the second draft of this PEP, I came to the conclusion that the readability of hybrid Python 2/3 mapping code can actually be best enhanced by better helper functions rather than by making changes to Python 3.5+. The main value I now see in this PEP is as a clear record of the recommended approaches to migrating mapping iteration code from Python 2 to Python 3, as well as suggesting ways to keep things readable and maintainable when writing hybrid code that supports both versions. Notably, I recommend that hybrid code avoid calling mapping iteration methods directly, and instead rely on builtin functions where possible, and some additional helper functions for cases that would be a simple combination of a builtin and a mapping method in pure Python 3 code, but need to be handled slightly differently to get the exact same semantics in Python 2. Static code checkers like pylint could potentially be extended with an optional warning regarding direct use of the mapping iteration methods in a hybrid code base. Mapping iteration models Python 2.7 provides three different sets of methods to extract the keys, values and items from a ``dict`` instance, accounting for 9 out of the 18 public methods of the ``dict`` type. In Python 3, this has been rationalised to just 3 out of 11 public methods (as the ``has_key`` method has also been removed). Lists as mutable snapshots -- This is the oldest of the three styles of dict iteration, and hence the one implemented by the ``d.keys()``, ``d.values()`` and ``d.items()`` methods in Python 2. These methods all return lists that are snapshots of the state of the mapping at the time the method was called. This has a few consequences: * the original object can be mutated freely without affecting iteration over the snapshot * the snapshot can be modified independently of the original object * the snapshot consumes memory proportional to the size of the original mapping The semantic equivalent of these operations in Pyt
