Re: [Python-Dev] Status of C compilers for Python on Windows
On 10 October 2014 02:29, Victor Stinner wrote: > The free version (Visual Studio Express) only supports 32-bit > VC++ 2008/2010 EE do not *bundle* a 64-bit compiler, but it's certainly possible to build 64-bit applications by using the compiler in the (also free) Windows SDK: http://jenshuebel.wordpress.com/2009/02/12/visual-c-2008-express-edition-and-64-bit-targets/ https://stackoverflow.com/questions/1865069/how-to-compile-a-64-bit-application-using-visual-c-2010-express ___ 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] Spreading the Python 3 religion
On 1 March 2012 12:11, Stefan Krah wrote: > Advantages of separate branches: > Even though I agree on most of your points, I disagree with 2) Neither version is a second class citizen. In my experience, this is only true if you have a very strict discipline, or if both branches are used a lot. If there are two branches (say: py2 and py3), and one is used much less (say: py3), that one will always be the second class citizen - the py2 branch, which is used by 'most people' gets more feature requests and bug reports. People will implement the features and bug fixes in the py2 branch, and sometimes forget to port them to the py3 branch, which means the branches start diverging. This divergence makes applying newer changes even more difficult, leading to further divergence. Another cause for this is the painful merging in most version control systems. I'm guessing you all know the pain of 'svn merge' - and there are a *lot *of projects still using SVN or even CVS. As such, you need to impose the discipline to always apply changes to both branches. This is a reasonable thing for larger projects, but it is generally harder to implement it for smaller projects, as you're already lucky people are actually contributing. Best, Merlijn ___ 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
[Python-Dev] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
http://bugs.python.org/issue6784 ("byte/unicode pickle
incompatibilities between python2 and python3")
Hello all,
Currently, pickle unpickles python2 'str' objects as python3 'str'
objects, where the encoding to use is passed to the Unpickler.
However, there are cases where it makes more sense to unpickle a
python2 'str' as python3 'bytes' - for instance when it is actually
binary data, and not text.
Currently, the mapping is as follows, when reading a pickle:
python2 'str' -> python3 'str' (using an encoding supplied to Unpickler)
python2 'unicode' -> python3 'str'
or, when creating a pickle using protocol <= 2:
python3 'str' -> python2 'unicode'
python3 'bytes' -> python2 '__builtins__.bytes object'
This issue suggests to add a flag to change the behaviour as follows:
a) python2 'str' -> python3 'bytes'
b) python3 'bytes' -> python2 'str'
The question on this is how to pass this flag. To quote Antoine (with
permission) on my mail about this issue on core-mentorship:
> I haven't answered because I'm unsure about the approach itself - do we
> want to add yet another argument to pickle methods, especially this late
> in the 3.x development cycle?
Currently, I have implemented it using an extra argument for the
Pickler and Unpickler objects ('bytestr'), which toggles the
behaviour. I.e.:
>>> pickled = Pickler(data, bytestr=True); unpickled = Unpickler(data,
>>> bytestr=True).
This is the approach used in pickle_bytestr.patch [1]
Another option would be to implement a seperate Pickler/Unpickler
object, such that
>>> pickled = BytestrPickler(data, bytestr=True); unpickled =
>>> BytestrUnpickler(data, bytestr=True)
This is the approach I initially implemented [2].
Alternatively, there is the option only to implement the Unpickler,
leaving the Pickler as it is. This allows
>>> unpickled = Unpickler(data, encoding=bytes)
where the bytes type is used as a special 'flag'.
And, of course, there is the option not to implement this in the stdlib at all.
What are your ideas on this?
Best,
Merlijn
[0] http://bugs.python.org/issue6784
[1] http://bugs.python.org/file24719/pickle_bytestr.patch
[2] https://github.com/valhallasw/py2/blob/master/bytestrpickle.py
___
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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
Oops. I should re-read my mails before I send them, not /after/ I send them. On 13 March 2012 12:44, Merlijn van Deen wrote: >>>> pickled = BytestrPickler(data, bytestr=True); unpickled = >>>> BytestrUnpickler(data, bytestr=True) should of course read >>>> pickled = BytestrPickler(data); unpickled = BytestrUnpickler(data) Sorry about that. Merlijn ___ 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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
On 13 March 2012 22:13, Guido van Rossum wrote: > Well, since trying to migrate data between versions using pickle is > the "wrong" thing anyway, I think the status quo is just fine. > Developers doing the "right" thing don't use pickle for this purpose. I'm confused by this. "The pickle serialization format is guaranteed to be backwards compatible across Python releases" [1], which - at least to me - suggests it's fine to use pickle for long-term storage, and that reading this data in new Python versions is not a "bad" thing to do. Am I missing something here? [1] http://docs.python.org/library/pickle.html#the-pickle-protocol ___ 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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
Hi Guido,
Let me start with thanking you for your long reply. It has clarified
some points to me, but I am still not certain about some others. I
hope I can clarify why I'm confused about this issue in the following.
First of all, let me clarify that I wrote my original mail not as 'the
guy who wants to serialize stuff' but as 'the guy who wonders what the
best way to implement it in python is'. Of course, 'not' is a
reasonable answer to that question.
On 13 March 2012 23:08, Guido van Rossum wrote:
> That was probably written before Python 3. Python 3 also dropped the
> long-term backwards compatibilities for the language and stdlib. I am
> certainly fine with adding a warning to the docs that this guarantee
> does not apply to the Python 2/3 boundary. But I don't think we should
> map 8-bit str instances from Python 2 to bytes in Python 3.
Yes, backwards compatibility was dropped, but the current pickle
module tries to work around this by using a module mapping [1] and
aids in loading 8-bit str instances by asking for an encoding [2].
Last, but not least, we can /write/ old version pickles, for which
the same module mapping is used, but in reverse. As such, the module
suggests in many ways that it should be possible to interchange
pickles between python 2 and python 3.
> My snipe was mostly in reference to the many other things that can go
> wrong with pickled data as your environment evolves (...)
I understand your point. However, my interpretation of this issue
always was 'if you only pickle built-in types, you'll be fine' - which
is apparently wrong.
Essentially - my point is this: considering the pickle module is
already using several compatibility tricks and considering I am not
the only one who would like to read binary data from a pickle in
python 3 - even though it might not be the 'right' way to do it - what
is there /against/ adding the possibility?
Last but not least, this is what people are now doing instead: [1]
s = pickle.load(f, encoding='latin1')
b = s.encode('latin1')
print(zlib.decompress(b))
Which hurts my eyes.
In any case - again, thanks for taking the time to respond. I hope I
somewhat clarified why I was/am somewhat confused on the issue, and
the reasons why I think that it is still a good idea ;-)
Best,
Merlijn
[1] http://hg.python.org/cpython/file/8b2668e60aef/Lib/_compat_pickle.py
[2] http://docs.python.org/dev/library/pickle.html#module-interface
[3]
http://stackoverflow.com/questions/4281619/unpicking-data-pickled-in-python-2-5-in-python-3-1-then-uncompressing-with-zlib
___
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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
On 17 March 2012 00:57, Guido van Rossum wrote:
> OK, how about using encoding=bytes (yes, the type object!)? Or 'bytes' ?
encoding=bytes makes (at least intuitive) sense to me;
encoding='bytes' would imply there is an encoding with name 'bytes'
that somehow does b''.decode('bytes')=b'', and would disallow anyone
to create a new encoding with the name 'bytes'.
I'll take a look at rewriting my patch later this weekend, and I'll
also give the documentation (both the 'consider not using pickle for
long time storage' and the docs for this setting) some thought.
Best,
Merlijn
___
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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
On 17 March 2012 10:43, Stefan Behnel wrote: > In lxml, there was an "encoding=unicode" option that would let the > XML/HTML/text serialisation function return a Unicode string. This was > eventually deprecated in favour of "encoding='unicode'" when ElementTree > gained this feature as well some years later. That's this issue: http://bugs.python.org/issue8047 The thread also suggests the options encoding=False and encoding=None Considering ET uses encoding="unicode" to signal 'don't encode', I agree with you that using encoding="bytes" to signal 'don't encode' would be sensible. However, ET /also/ allows encoding=str.What about allowing both encoding="bytes" /and/ encoding=bytes? Best, Merlijn ___ 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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
On 17 March 2012 16:28, Serhiy Storchaka wrote: > Thus, there are no reasons to use bytes instead of 'bytes'. Aesthetics ;-) I've implemented the encoding="bytes" version [1]. Thank you all for your input! Merlijn [1] http://bugs.python.org/issue6784#msg156166 ___ 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 install layout and the PATH on win32
On 13 March 2012 20:43, VanL wrote:
> Following up on conversations at PyCon, I want to bring up one of my
> personal hobby horses for change in 3.3: Fix install layout on Windows, with
> a side order of making the PATH work better.
As this is being considered an 'incompatible change' on the bug
tracker item [1] in any case, I'd like to mention that this might also
be a convenient moment to re-think the default install location. After
all, software is supposed to be installed in %programfiles% on
windows, not in c:\.
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in c:\pythonxy:
1 - issues due to spaces ('Program Files') or non-ascii characters in
the path ('Fișiere Program' on a Romanian windows). These issues are
supposed to be fixed by now (?).
2 - issues due to permissions - installing python / packages in
%programfiles% may require administrator rights.
Historical note: in python 1.5 the install location was changed to
\program files\.., but in python 1.6/2.0 it was changed (back?) to
\pythonxy. [2 @ 10618, 10850, 13804]
[1] http://bugs.python.org/issue14302
[2] http://hg.python.org/cpython/file/a5add01e96be/Misc/HISTORY
___
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
