Re: [Python-Dev] Accepting PEP 3154 for 3.4?

[Alexandre Vassalotti]

On Tue, Nov 19, 2013 at 2:09 PM, Antoine Pitrou  wrote:
>
> Well, I don't think it's a big deal to add a FRAME opcode if it doesn't
> change the current framing logic. I'd like to defer to Alexandre on this
> one, anyway.


Looking at the different options available to us:

1A. Mandatory framing
  (+) Allows the internal buffering layer of the Unpickler to rely
  on the presence of framing to simplify its implementation.
  (-) Forces all implementations of pickle to include support for
  framing if they want to use the new protocol.
  (-) Cannot be removed from future versions of the Unpickler
  without breaking protocols which mandates framing.
1B. Optional framing
  (+) Could allow optimizations to disable framing if beneficial
  (e.g., when pickling to and unpickling from a string).

2A. With explicit FRAME opcode
  (+) Makes optional framing simpler to implement.
  (+) Makes variable-length encoding of the frame size simpler
  to implement.
  (+) Makes framing visible to pickletools.
  (-) Adds an extra byte of overhead to each frames.
2B. No opcode

3A. With fixed 8-bytes headers
 (+) Is simple to implement
 (-) Adds overhead to small pickles.
3B. With variable-length headers
 (-) Requires Pickler implemention to do extra data copies when
 pickling to strings.

4A. Framing baked-in the pickle protocol
 (+) Enables faster implementations
4B. Framing through a specialized I/O buffering layer
 (+) Could be reused by other modules

I may change my mind as I work on the implementation, but at least for now,
I think the combination of 1B, 2A, 3A, 4A will be a reasonable compromise
here.
___
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] Accepting PEP 456 (Secure hash algorithm)

[Nick Coghlan]

Christian has indicated he now considers PEP 456, which adds an updated and
configurable hash algorithm ready for pronouncement (
http://www.python.org/dev/peps/pep-0456/)

I am happy the PEP and the associated implementation represent a desirable
improvement to CPython, and approve of the proposal to experiment further
with the small string optimisation during the beta period, before either
enabling it or removing it entirely in beta 2.

Accordingly, I am formally accepting the PEP for inclusion in Python 3.4 :)

Regards,
Nick.
___
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] Accepting PEP 456 (Secure hash algorithm)

[Christian Heimes]

Am 20.11.2013 11:07, schrieb Nick Coghlan:
> Christian has indicated he now considers PEP 456, which adds an updated
> and configurable hash algorithm ready for pronouncement
> (http://www.python.org/dev/peps/pep-0456/)
> 
> I am happy the PEP and the associated implementation represent a
> desirable improvement to CPython, and approve of the proposal to
> experiment further with the small string optimisation during the beta
> period, before either enabling it or removing it entirely in beta 2.
> 
> Accordingly, I am formally accepting the PEP for inclusion in Python 3.4 :)

Thanks a lot, Nick! :)

The PEP has landed in revision
http://hg.python.org/cpython/rev/adb471b9cba1 . I don't expect any test
failures as I have tested the PEP on a lot of platforms. The new code
compiles and passes its tests on Linux, Windows, BSD, HUPX, Solaris with
all supported CPUs (little and big endian, 32 bit and 64 bit).

Christian
___
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] Accepting PEP 456 (Secure hash algorithm)

[Victor Stinner]

2013/11/20 Christian Heimes :
> The PEP has landed in revision
> http://hg.python.org/cpython/rev/adb471b9cba1 . I don't expect any test
> failures as I have tested the PEP on a lot of platforms. The new code
> compiles and passes its tests on Linux, Windows, BSD, HUPX, Solaris with
> all supported CPUs (little and big endian, 32 bit and 64 bit).

It looks like dict, set and frozenset representation (repr(...)) now
depends on the platform (probably 32 bit vs 64 bit), even if
PYTHONHASHSEED is set. I don't know if it's an issue or not.

This is why test_gdb was failing. I fixed test_gdb in:
http://hg.python.org/cpython/rev/11cb1c8faf11

The fix runs Python with a fixed PYTHONHASHSEED to get repr(value),
and then compare it to the value from gdb.

Victor
___
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] Accepting PEP 456 (Secure hash algorithm)

[Victor Stinner]

2013/11/20 Victor Stinner :
> It looks like dict, set and frozenset representation (repr(...)) now
> depends on the platform (probably 32 bit vs 64 bit), even if
> PYTHONHASHSEED is set. I don't know if it's an issue or not.

In Python 3.3, repr(set("abcd")) with PYTHONHASHSEED=0 always give
"{'a', 'c', 'b', 'd'}" on 32 bit and 64 bit platforms.

In Python 3.4, repr(set("abcd")) with PYTHONHASHSEED=0 now gives
"{'b', 'a', 'c', 'd'}" on 32 bit.and  "{'a', 'b', 'c', 'd'}" on 64
bit.

Victor
___
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] Accepting PEP 456 (Secure hash algorithm)

[Christian Heimes]

Am 20.11.2013 12:41, schrieb Victor Stinner:
> 2013/11/20 Victor Stinner :
>> It looks like dict, set and frozenset representation (repr(...))
>> now depends on the platform (probably 32 bit vs 64 bit), even if 
>> PYTHONHASHSEED is set. I don't know if it's an issue or not.
> 
> In Python 3.3, repr(set("abcd")) with PYTHONHASHSEED=0 always give 
> "{'a', 'c', 'b', 'd'}" on 32 bit and 64 bit platforms.
> 
> In Python 3.4, repr(set("abcd")) with PYTHONHASHSEED=0 now gives 
> "{'b', 'a', 'c', 'd'}" on 32 bit.and  "{'a', 'b', 'c', 'd'}" on 64 
> bit.

I have fixed the problem in
http://hg.python.org/cpython/rev/961d832d8734 . My attempt to mix the
hash's MSB into LSB for 32 bit builds was the culprit. It should be
secure enough without the op.

___
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] Which direction is UnTransform? / Unicode is different

[Steven D'Aprano]

On Tue, Nov 19, 2013 at 05:28:48PM -0800, Jim J. Jewett wrote:
> 
>  
> (Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote:
> 
>  > Serhiy Storchaka wrote:
> 
>  > > If the transform() method will be added, I prefer to have only
>  > > one transformation method and specify a direction by the
>  > > transformation name ("bzip2"/"unbzip2").
> 
> Me too.  Until I consider special cases like "compress", or "lower",
> and realize that there are enough special cases to become a major wart
> if generic transforms ever became popular.  

I'm not sure I understand this comment. Why are "compress" and "lower" 
special cases? If there's a "compress" codec, presumably there'll be an 
"uncompress" or "expand" that reverses it. In the case of "lower", it's 
not losslessly reversable, but there's certainly a reverse 
transformation, "upper".

Some transformations are their own reverse, e.g. "rot13". In that case, 
there's no need for an unrot13 codec, since applying it twice undoes 
it.


> > People think about these transformations as "en- or de-coding", not
> > "transforming", most of the time.  Even for a transformation that is
> > an involution (eg, rot13), people have an very clear idea of what's
> > encoded and what's not, and they are going to prefer the names
> > "encode" and "decode" for these (generic) operations in many cases.
> 
> I think this is one of the major stumbling blocks with unicode.
> 
> I originally disagreed strongly with what Stephen wrote -- but then
> I realized that all my counterexamples involved unicode text.

Counterexamples to what? Again, I'm afraid I can't really understand 
what point you're trying to make here. Perhaps an explicit 
counterexample, and an explicit statement of what you're disagreeing 
with (e.g. "I disagree that people have a clear example of what's 
encoded and what's not") will help.

 
[...]
> But an 8-bit (even Latin-1, let alone ASCII) bytestring really doesn't
> seem "encoded", and it doesn't make sense to "decode" a perfectly
> readable (ASCII) string into a sequence of "code units".

Of course it is encoded. There's nothing "a"-like about the byte 0x61, 
byte 0x2E is nothing like a period, and there is nothing about the byte 
0x0A that forces text editors to start a new line -- or should that be 
0x0D, or even possibly 0x85?

There's nothing that distinguishes the text "spam" from the four-byte 
integer 1936744813 (0x7370616d in hex) except the semantics that we 
grant it, and that includes an implicit transformation 0x73 <-> "s", 
etc.

Reading this may help:

www.joelonsoftware.com/articles/Unicode.html‎


> Nor does it help that http://www.unicode.org/glossary/#code_unit
> defines "code unit" as "The minimal bit combination that can represent
> a unit of encoded text for processing or interchange. The Unicode
> Standard uses 8-bit code units in the UTF-8 encoding form, 16-bit code
> units in the UTF-16 encoding form, and 32-bit code units in the UTF-32
> encoding form. (See definition D77 in Section 3.9, Unicode Encoding
> Forms.)"

I agree that the official Unicode glossary is unfortunately confusing. 
It has a huge amount of information, often with confusingly similar 
terminology (code points and code units are, in a sense, opposites), and 
it's quite hard for beginners to Unicode to make sense of it all.

 
> I have to read that very carefully to avoid mentally translating it
> into "Code Units are *en*coded, 

Code units *are* encoded, in the sense that we say a burger is cooked. 
Take a raw meat patty and cook it, and you get a burger. Similarly, code 
units are the product of an encoding process, hence have been encoded.

Code points (think of them as characters, modulo a few technicalities) 
are encoded *into* code units, which are bytes. Which code units you 
get depend on the encoding form you use, i.e. the codec.

If you start with the character "a", and apply the UTF-8 encoding, 
you get a single 8-bit (one byte) code unit, 0x61. If you apply the 
UTF-16 (big endian) encoding, you get a single 16-bit (two bytes) 
code unit, 0x0061. If you apply UTF-32be codec, you get a single 32-bit 
(four bytes) code unit, 0x0061.


> and there are lots of different
> complicated encodings that I wouldn't use unless I were doing special
> processing or interchange."

Very few of those encodings are Unicode. With the exception of a small 
handful of UTF-* codecs, and maybe one or two others, the vast majority 
are legacy encodings from the Bad Old Days when just about every 
computer had it's own distinct character set, or sets. If you're a 
Windows user, the non-UTF codecs (all the Latin-whatever codecs, Big5, 
cp-whatever, koi8-whatever, there are dozens of them) are basically old 
Windows code pages and the equivalent from other computer systems.

And yes, it is best to avoid them like the plague except when you need 
them for interoperability with legacy data.


> If I'm not using the network, or if my
> "interchange format" already looks like read

Re: [Python-Dev] Which direction is UnTransform? / Unicode is different

[Chris Angelico]

On Wed, Nov 20, 2013 at 11:03 PM, Steven D'Aprano  wrote:
>> I *will* get confused over which
>> direction is encoding and which is decoding. (Removing .decode()
>> from the (unicode) str type in 3 does help a lot, if I have a Python 3
>> interpreter running to check against.)
>
> It took me a long time to learn that text encodes to bytes, and bytes
> decode back to text. Using Python 3 really helped with that.

Rule of thumb: Stuff gets encoded for transmission/storage and decoded
for usage.

That covers encryption (you transmit the coded form and read the
decoded), compression (you store the tighter form and use the
expanded), Unicode (you store bytes, you work with characters), and
quite a few others. I don't know that it's an iron-clad rule (though I
can't off-hand think of a contrary example), but it's certainly an
easy way to remember a lot of the encode/decode pairs.

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] PEP 428 - pathlib - ready for approval

[Garth Bushell]

I've noticed in pathlib.py the following error on line 39

if sys.getwindowsversion()[:2] >= (6, 0) and sys.version_info >= (3, 2):

it should be:-

if sys.getwindowsversion()[2:] >= (6, 0) and sys.version_info >= (3, 2):

I'm also quite uneasy on the case insensitive comparison on Windows as the
File system NTFS is case sensitive.

"""Current Windows file systems, like NTFS, are case-sensitive; that is a
readme.txt and a Readme.txt can exist in the same directory. Windows
disallows the user to create a second file differing only in case due to
compatibility issues with older software not designed for such
operation."""  (http://en.wikipedia.org/wiki/Case_sensitivity)

If people create .PY files it wouldn't work on Linux so why make it work on
windows?

Cheers

Garth



On 19 November 2013 22:06, Antoine Pitrou  wrote:
On Tue, 19 Nov 2013 17:02:15 -0500
Brett Cannon  wrote:
> On Tue, Nov 19, 2013 at 4:04 PM, Antoine Pitrou 
wrote:
>
> >
> > Hello,
> >
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form.  Here is the last call for any comments or
> > arguments against approval, before Guido marks the PEP accepted (or
> > changes his mind :-)).
> >
>
> Is 'ext' going to exist with 'suffix'? Seems redundant (I'm guessing the
> example is out-of-date and 'ext' was changed to suffix).
>
> And a very minor grammatical thing: "you have to lookup a dedicate
> attribute" -> "dedicated"

Thanks. Both errors are now fixed.

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/garth%40garthy.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 428 - pathlib - ready for approval

[Antoine Pitrou]

On Wed, 20 Nov 2013 12:25:20 +
Garth Bushell  wrote:
> 
> I'm also quite uneasy on the case insensitive comparison on Windows as the
> File system NTFS is case sensitive.
> 
> """Current Windows file systems, like NTFS, are case-sensitive; that is a
> readme.txt and a Readme.txt can exist in the same directory. Windows
> disallows the user to create a second file differing only in case due to
> compatibility issues with older software not designed for such
> operation."""  (http://en.wikipedia.org/wiki/Case_sensitivity)

Well the path class is named WindowsPath, not NTFSPath. In other words,
it embodies path semantics as exposed by the Windows system and API,
not what NTFS is able to do. Having per-filesystem concrete path
classes would quickly grow of control (do we need a separate class for
FAT32 filesystems? what if Windows later switches to another
filesystem?).

The PEP already points to a corresponding discussion:
http://www.python.org/dev/peps/pep-0428/#case-sensitivity

> If people create .PY files it wouldn't work on Linux so why make it work on
> windows?

What do you mean with "work"?
What I know is that if I save a something.PY file under Windows and then
double-click on it in the Explorer, it will be launched with the Python
interpreter.

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] Which direction is UnTransform? / Unicode is different

[Walter Dörwald]

On 20.11.13 02:28, Jim J. Jewett wrote:


[...]
Instead of relying on introspection of .decodes_to and .encodes_to, it
would be useful to have charsetcodecs and tranformcodecs as entirely
different modules, with their own separate registries.  I will even
note that the existing help(codecs) seems more appropriate for
charsetcodecs than it does for the current conjoined module.


I don't understand how a registry of transformation functions would 
simplify code. Without the transform() method I would write:


   >>> import binascii
   >>> binascii.hexlify(b'foo')
   b'666f6f'

With the transform() method I should be able to write:

   >>> b'foo'.transform("hex")

However how does the hex transformer get registered in the registry? If 
the hex transformer is not part of the stdlib, there must be some code 
that does the registration, but to get that code to execute, I'd have to 
import a module, so we're back to square one, as I'd have to write:


   >>> import hex_transformer
   >>> b'foo'.transform("hex")

A way around this would be some kind of import magic, but is this really 
neccessary to be able to avoid one import statement?


Furthermore different transformation functions might have different 
additional options. Supporting those is simple when we have simple 
transformation functions: The functions has arguments, and those are 
documented where the function is documented. If we want to support 
custom options for the .transform() method, transform() would have to 
pass along *args, **kwargs to the underlying transformer. However this 
is difficult to document in a way that makes it easy to find which 
options exist for a particular transformer.


Servus,
   Walter

___
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] Which direction is UnTransform? / Unicode is different

[Nick Coghlan]

On 20 November 2013 23:38, Walter Dörwald  wrote:
> On 20.11.13 02:28, Jim J. Jewett wrote:
>
>> [...]
>>
>> Instead of relying on introspection of .decodes_to and .encodes_to, it
>> would be useful to have charsetcodecs and tranformcodecs as entirely
>> different modules, with their own separate registries.  I will even
>> note that the existing help(codecs) seems more appropriate for
>> charsetcodecs than it does for the current conjoined module.
>
>
> I don't understand how a registry of transformation functions would simplify
> code. Without the transform() method I would write:
>
>>>> import binascii
>>>> binascii.hexlify(b'foo')
>b'666f6f'
>
> With the transform() method I should be able to write:
>
>>>> b'foo'.transform("hex")
>
> However how does the hex transformer get registered in the registry? If the
> hex transformer is not part of the stdlib, there must be some code that does
> the registration, but to get that code to execute, I'd have to import a
> module, so we're back to square one, as I'd have to write:
>
>>>> import hex_transformer
>>>> b'foo'.transform("hex")
>
> A way around this would be some kind of import magic, but is this really
> neccessary to be able to avoid one import statement?

Could we please move discussion of hypothetical future divisions of
the codec namespace into additional APIs to python-ideas? We don't
even have consensus to restore the codecs module to parity with its
Python 2 functionality at this point, let alone agreement on adding
more convenience APIs for functionality that we have core developers
arguing shouldn't be restored at all.

Regards,
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

Re: [Python-Dev] PEP 428 - pathlib - ready for approval

[Ethan Furman]

On 11/20/2013 04:25 AM, Garth Bushell wrote:


I'm also quite uneasy on the case insensitive comparison on Windows as the File 
system NTFS is case sensitive.


No, it's case-preserving.


"""Current Windows file systems, like NTFS, are case-sensitive; that is a 
readme.txt and a Readme.txt can exist in the
same directory. Windows disallows the user to create a second file differing 
only in case due to compatibility issues
with older software not designed for such operation."""  
(http://en.wikipedia.org/wiki/Case_sensitivity)


I just did some tests on my Win7 NTFS file system and I was unable to get two files in the same directory which differed 
only by case using either cmd or explorer.



If people create .PY files it wouldn't work on Linux so why make it work on 
windows?


Because it *does* work on windows.

  c:\temp > copy con: hello.PY
  print "Hello World!"
  ^Z

  c:\temp > \python273\python
  --> import hello
  Hello World!

Just one of the many things to be aware of if attempting to write 
cross-platform code.

--
~Ethan~
___
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 428 - pathlib - ready for approval

[Guido van Rossum]

On Wed, Nov 20, 2013 at 4:49 AM, Antoine Pitrou  wrote:

> On Wed, 20 Nov 2013 12:25:20 +
> Garth Bushell  wrote:
> >
> > I'm also quite uneasy on the case insensitive comparison on Windows as
> the
> > File system NTFS is case sensitive.
> >
> > """Current Windows file systems, like NTFS, are case-sensitive; that is a
> > readme.txt and a Readme.txt can exist in the same directory. Windows
> > disallows the user to create a second file differing only in case due to
> > compatibility issues with older software not designed for such
> > operation."""  (http://en.wikipedia.org/wiki/Case_sensitivity)
>
> Well the path class is named WindowsPath, not NTFSPath. In other words,
> it embodies path semantics as exposed by the Windows system and API,
> not what NTFS is able to do. Having per-filesystem concrete path
> classes would quickly grow of control (do we need a separate class for
> FAT32 filesystems? what if Windows later switches to another
> filesystem?).
>
> The PEP already points to a corresponding discussion:
> http://www.python.org/dev/peps/pep-0428/#case-sensitivity
>
> > If people create .PY files it wouldn't work on Linux so why make it work
> on
> > windows?
>
> What do you mean with "work"?
> What I know is that if I save a something.PY file under Windows and then
> double-click on it in the Explorer, it will be launched with the Python
> interpreter.
>

Also, let's not forget that apart from comparison (Path('a') == Path('A')),
matching and globbing, the WindowsPath class does not normalize the case of
pathname components (only slash vs. backslash, redundant [back]slashes, and
redundant '.' components are handled). So if you are in the unusual
circumstances where you have to use case-sensitive paths on Windows, you
can still use WindowsPath.

-- 
--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] Accepting PEP 3154 for 3.4?

[Martin v. Löwis]

Am 20.11.13 06:18, schrieb Tim Peters:
> BTW, I'm not a web guy:  in what way is HTTP chunked transfer mode
> viewed as being flawed?  Everything I ever read about it seemed to
> think it was A Good Idea.

It just didn't work for some time, see e.g.

http://bugs.python.org/issue1486335
http://bugs.python.org/issue1966
http://bugs.python.org/issue1312980
http://bugs.python.org/issue3761

It's not that the protocol was underspecified - just the implementation
was "brittle" (if I understand that word correctly). And I believe (and
agree with you) that the cause for this "difficult to implement"
property is that the framing is in putting framing "in the middle"
of the stack (i.e. not really *below* pickle itself, but into pickle
but below the opcodes - just like http chunked transfer is "in" http,
but below the content encoding).

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/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 3154 for 3.4?

[Guido van Rossum]

A problem with chunked IIRC is that the frame headers are variable-length
(a CRLF followed by a hex number followed by some optional gunk followed by
CRLF) so you have to drop back into one-byte-at-a-time to read it. (Well, I
suppose you could read 5 bytes, which is the minimum: CR, LF, X, CR, LF,
and when the second CR isn't among these, you have a lower bound for how
much more to read, although at that point you better load up on coffee
before writing the rest of the code. :-)

Some good things about it:

- Explicit final frame (byte count zero), so no need to rely on the data to
know the end.

- The redundancy in the format (start and end with CRLF, hex numbers) makes
it more likely that framing errors (e.g. due to an incorrect counting or
some layer collapsing CRLF into LF) are detected.


On Wed, Nov 20, 2013 at 7:44 AM, "Martin v. Löwis" wrote:

> Am 20.11.13 06:18, schrieb Tim Peters:
> > BTW, I'm not a web guy:  in what way is HTTP chunked transfer mode
> > viewed as being flawed?  Everything I ever read about it seemed to
> > think it was A Good Idea.
>
> It just didn't work for some time, see e.g.
>
> http://bugs.python.org/issue1486335
> http://bugs.python.org/issue1966
> http://bugs.python.org/issue1312980
> http://bugs.python.org/issue3761
>
> It's not that the protocol was underspecified - just the implementation
> was "brittle" (if I understand that word correctly). And I believe (and
> agree with you) that the cause for this "difficult to implement"
> property is that the framing is in putting framing "in the middle"
> of the stack (i.e. not really *below* pickle itself, but into pickle
> but below the opcodes - just like http chunked transfer is "in" http,
> but below the content encoding).
>
> 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/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 428 - pathlib - ready for approval

[Eric V. Smith]

On 11/20/2013 09:01 AM, Ethan Furman wrote:
> On 11/20/2013 04:25 AM, Garth Bushell wrote:
>>
>> I'm also quite uneasy on the case insensitive comparison on Windows as
>> the File system NTFS is case sensitive.
> 
> No, it's case-preserving.
> 
>> """Current Windows file systems, like NTFS, are case-sensitive; that
>> is a readme.txt and a Readme.txt can exist in the
>> same directory. Windows disallows the user to create a second file
>> differing only in case due to compatibility issues
>> with older software not designed for such operation.""" 
>> (http://en.wikipedia.org/wiki/Case_sensitivity)
> 
> I just did some tests on my Win7 NTFS file system and I was unable to
> get two files in the same directory which differed only by case using
> either cmd or explorer.

I think the confusion comes from the difference between what NTFS can do
and what the Win32 (or whatever it's now called) layer allows you to do.
Rumor has it that the old Posix subsystem allowed NTFS to create 2 files
in the same directory that differed only by case.

"Filenames are Case Sensitive on NTFS Volumes"
http://support.microsoft.com/kb/100625

I realize that for practical purposes, NTFS is seen as case-preserving,
but deep down inside it's case-sensitive.

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 428 - pathlib - ready for approval

[Guido van Rossum]

On Wed, Nov 20, 2013 at 6:01 AM, Ethan Furman  wrote:

> On 11/20/2013 04:25 AM, Garth Bushell wrote:
>
>>
>> I'm also quite uneasy on the case insensitive comparison on Windows as
>> the File system NTFS is case sensitive.
>>
>
> No, it's case-preserving.
>

It's quite possible that you are both right -- possibly the filesystem
driver supports foo and FOO in the same directory but the kernel I/O layer
prohibits that. Stranger things have happened. (IIRC the behavior might
have been intended so that NT could get a "POSIX compliant" stamp of
approval -- using a different set of kernel interfaces that don't enforce
case insensitive matching.)

-- 
--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 428 - pathlib - ready for approval

[Xavier Morel]

On 2013-11-20, at 17:09 , Guido van Rossum  wrote:

> On Wed, Nov 20, 2013 at 6:01 AM, Ethan Furman  wrote:
> On 11/20/2013 04:25 AM, Garth Bushell wrote:
> 
> I'm also quite uneasy on the case insensitive comparison on Windows as the 
> File system NTFS is case sensitive.
> 
> No, it's case-preserving.
> 
> It's quite possible that you are both right -- possibly the filesystem driver 
> supports foo and FOO in the same directory but the kernel I/O layer prohibits 
> that. Stranger things have happened. (IIRC the behaviour might have been 
> intended so that NT could get a "POSIX compliant" stamp of approval -- using 
> a different set of kernel interfaces that don't enforce case insensitive 
> matching.)

The Subsystem for Unix-based Applications (SUA, formerly WSU and née
Interix) does expose NTFS’s case sensitivity, but FWIW it was
originally developed outside of Microsoft and independently from NTFS
(and a few years later).

It looks like NTFS’s designers simply didn’t feel completely
beholden to the limitations of the Windows API.

___
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 428 - pathlib - ready for approval

[Martin v. Löwis]

Am 20.11.13 17:04, schrieb Eric V. Smith:
> I think the confusion comes from the difference between what NTFS can do
> and what the Win32 (or whatever it's now called) layer allows you to do.
> Rumor has it that the old Posix subsystem allowed NTFS to create 2 files
> in the same directory that differed only by case.

Actually, the Windows API *does* support case-sensitivity in file names,
through the FILE_FLAG_POSIX_SEMANTICS flag to CreateFileW.

Unfortunately, in recent Windows versions, the kernel object manager
(a layer above the file system driver, but below the Windows API)
started setting the kernel variable for case insensitivity of object
names to true, defeating the purpose of this flag:

http://support.microsoft.com/kb/929110

So if you set ObCaseInsensitive to 0, reboot, then use CreateFileW
with FILE_FLAG_POSIX_SEMANTICS, then you should be able to create
two files in the same directory that differ only in case - i.e. the
system would be case-sensitive.

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/archive%40mail-archive.com

[Python-Dev] PEP 3156 (asyncio) formally accepted

[Antoine Pitrou]

Hello,

I have decided to mark PEP 3156 accepted. This reflects the fact that
the implementation is now in the stdlib tree, and its API has been
pretty much validated during all previous discussions (mostly on the
tulip mailing-list).

I cannot stress enough that the main preoccupation right now should be
to write and integrate module docs inside the CPython source tree :-)

Congratulations to Guido and all people involved! This is a large and
very significant addition to the stdlib, and as far as I can tell both
design and implementation have benefitted from the contributions of many
people (perhaps someone should add them to Misc/ACKS?).

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 3156 (asyncio) formally accepted

[Guido van Rossum]

Thanks Antoine!

I will stop pretending to myself that I can finish the PEP this week and
instead focus on getting the docs in the CPython repo bootstrapped.

I would also like to thank the many contributors to the design and
implementation. (I've tried to mention everyone in the PEP's
Acknowledgements section -- if you know of someone who has contributed but
isn't mentioned yet, please let me know.)

It's been a great ride! (And it isn't over yet. :-)

--Guido


On Wed, Nov 20, 2013 at 10:08 AM, Antoine Pitrou wrote:

>
> Hello,
>
> I have decided to mark PEP 3156 accepted. This reflects the fact that
> the implementation is now in the stdlib tree, and its API has been
> pretty much validated during all previous discussions (mostly on the
> tulip mailing-list).
>
> I cannot stress enough that the main preoccupation right now should be
> to write and integrate module docs inside the CPython source tree :-)
>
> Congratulations to Guido and all people involved! This is a large and
> very significant addition to the stdlib, and as far as I can tell both
> design and implementation have benefitted from the contributions of many
> people (perhaps someone should add them to Misc/ACKS?).
>
> 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/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

[Python-Dev] PEP 0404 and VS 2010

[Christian Tismer]

Howdy friends,

according to pep 404, there will never be an official Python 2.8.
The migration path is from 2.7 to 3.x.

I agree with this strategy in almost all consequences but this one:

Many customers are forced to stick with Python 2.X because of other
products, but they require a Python 2.X version which can be compiled
using Visual Studio 2010 or better.
This is considered an improvement and not a bug fix, where I disagree.

So I see many Python 2.7 repositories on BB/GH which are hacked to support
VS 2010, but they are not converted with the same quality in mind
that fits our standards.


My question
---

I have created a very clean Python 2.7.6+ based CPython with the Stackless
additions, that compiles with VS 2010, using the adapted project structure
of Python 3.3.X, and I want to publish that on the Stackless website as the
official "Stackless Python 2.8". If you consider Stackless as official ;-) .

This compiler change is currently the only deviation from CPython 2.7,
but we may support a few easy back-ports on customer demand. We don'd add
any random stuff, of course.

My question is if that is safe to do:
Can I rely on PEP 404 that the "Python 2.8" namespace never will clash
with CPython?

And if not, what do you suggest then?
It will be submitted by end of November, thanks for your quick responses!

all the best -- Chris

--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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 0404 and VS 2010

[Joao S. O. Bueno]

I'd say publishing a high profile installable code with a "python 2.8" name
would cause a lot of undesired confusion to start with.

I usually lecture on Python to present the language to college students and
I.T. workers - and explaining away the current versioning scheme (use
either 2.7 or 3.3) is hard already. Having to add an explanation about a
downloadable and installable Python 2.8 that would be incompatible with
extensions compiled in Pypi would be tough. and I doubt it could even be
done without making your project look bad on the process.

Can't you just mark it as "visual studio 2010" version instead?

   js
 -><-





On 20 November 2013 18:52, Christian Tismer  wrote:

> Howdy friends,
>
> according to pep 404, there will never be an official Python 2.8.
> The migration path is from 2.7 to 3.x.
>
> I agree with this strategy in almost all consequences but this one:
>
> Many customers are forced to stick with Python 2.X because of other
> products, but they require a Python 2.X version which can be compiled
> using Visual Studio 2010 or better.
> This is considered an improvement and not a bug fix, where I disagree.
>
> So I see many Python 2.7 repositories on BB/GH which are hacked to support
> VS 2010, but they are not converted with the same quality in mind
> that fits our standards.
>
>
> My question
> ---
>
> I have created a very clean Python 2.7.6+ based CPython with the Stackless
> additions, that compiles with VS 2010, using the adapted project structure
> of Python 3.3.X, and I want to publish that on the Stackless website as the
> official "Stackless Python 2.8". If you consider Stackless as official ;-)
> .
>
> This compiler change is currently the only deviation from CPython 2.7,
> but we may support a few easy back-ports on customer demand. We don'd add
> any random stuff, of course.
>
> My question is if that is safe to do:
> Can I rely on PEP 404 that the "Python 2.8" namespace never will clash
> with CPython?
>
> And if not, what do you suggest then?
> It will be submitted by end of November, thanks for your quick responses!
>
> all the best -- Chris
>
> --
> Christian Tismer :^)   
> Software Consulting  : Have a break! Take a ride on Python's
> Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
> 14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
> PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
>   whom do you want to sponsor today?   http://www.stackless.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/
> 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] PEP 428 - pathlib - ready for approval

[Giampaolo Rodola']

On Tue, Nov 19, 2013 at 10:04 PM, Antoine Pitrou wrote:

>
> Hello,
>
> Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> latest amended form.  Here is the last call for any comments or
> arguments against approval, before Guido marks the PEP accepted (or
> changes his mind :-)).
>
> Regards
>
> Antoine.
>


Isn't this redundant?

>>> Path.cwd()
PosixPath('/home/antoine/pathlib')

Probably this is just personal taste but I'd prefer the more explicit:

>>> Path(os.getcwd())
PosixPath('/home/antoine/pathlib')

I understand all the os.* replication (Path.rename, Path.stat etc.) but all
these methods assume you're dealing with an instantiated Path instance
whereas Path.cwd is the only one which doesn't.
Not a big deal anyway, it just catched my eye because it's different.
Other than that the module looks absolutely awesome and a big improvement
over os.path!


--- Giampaolo
https://code.google.com/p/pyftpdlib/
https://code.google.com/p/psutil/
https://code.google.com/p/pysendfile/
___
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 428 - pathlib - ready for approval

[Guido van Rossum]

On Tue, Nov 19, 2013 at 1:04 PM, Antoine Pitrou  wrote:

> Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> latest amended form.  Here is the last call for any comments or
> arguments against approval, before Guido marks the PEP accepted (or
> changes his mind :-)).
>

Congrats Antoine! I've approved your PEP. Go ahead with the integration.

Everybody: pathlib is an immediately useful standard way for manipulating
file paths, both platform-specific and platform-independent (so you can
work with Windows paths on a POSIX system and vice versa).

pathlib  won't replace os.path immediately (the current status is
"provisional", which means that the API may still be tweaked after 3.4 is
released), but in the long term I expect os.path to die a quiet death (as
well as the host of 3rd party path modules that preceded pathlib).

Great job Antoine!

-- 
--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 428 - pathlib - ready for approval

[Antoine Pitrou]

On Wed, 20 Nov 2013 13:42:42 -0800
Guido van Rossum  wrote:
> On Tue, Nov 19, 2013 at 1:04 PM, Antoine Pitrou  wrote:
> 
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form.  Here is the last call for any comments or
> > arguments against approval, before Guido marks the PEP accepted (or
> > changes his mind :-)).
> >
> 
> Congrats Antoine! I've approved your PEP. Go ahead with the integration.
> 
> Everybody: pathlib is an immediately useful standard way for manipulating
> file paths, both platform-specific and platform-independent (so you can
> work with Windows paths on a POSIX system and vice versa).
> 
> pathlib  won't replace os.path immediately (the current status is
> "provisional", which means that the API may still be tweaked after 3.4 is
> released), but in the long term I expect os.path to die a quiet death (as
> well as the host of 3rd party path modules that preceded pathlib).

pathlib imports many modules at startup, so for scripts for which
startup time is critical using os.path may still be the best option.

But thanks anyway :)

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 0404 and VS 2010

[Christian Tismer]

My question is not answered at all, sorry Joao!
I did not ask a teacher for his opinion on Stackless, but the community 
about the

validity of pep 404.

I don't want a python 2.7 that does not install correctly, because people
don't read instructions. And exactly that will happen if I submit a modified
python 2.7 to PyPI.

This is a topic on Stackless Python, and I am asking python-dev before I 
do it.

But people know this has its limits.

cheers - chris


On 20/11/13 22:15, Joao S. O. Bueno wrote:
I'd say publishing a high profile installable code with a "python 2.8" 
name would cause a lot of undesired confusion to start with.


I usually lecture on Python to present the language to college 
students and I.T. workers - and explaining away the current versioning 
scheme (use either 2.7 or 3.3) is hard already. Having to add an 
explanation about a downloadable and installable Python 2.8 that would 
be incompatible with extensions compiled in Pypi would be tough. and I 
doubt it could even be done without making your project look bad on 
the process.


Can't you just mark it as "visual studio 2010" version instead?

   js
 -><-





On 20 November 2013 18:52, Christian Tismer > wrote:


Howdy friends,

according to pep 404, there will never be an official Python 2.8.
The migration path is from 2.7 to 3.x.

I agree with this strategy in almost all consequences but this one:

Many customers are forced to stick with Python 2.X because of other
products, but they require a Python 2.X version which can be compiled
using Visual Studio 2010 or better.
This is considered an improvement and not a bug fix, where I disagree.

So I see many Python 2.7 repositories on BB/GH which are hacked to
support
VS 2010, but they are not converted with the same quality in mind
that fits our standards.


My question
---

I have created a very clean Python 2.7.6+ based CPython with the
Stackless
additions, that compiles with VS 2010, using the adapted project
structure
of Python 3.3.X, and I want to publish that on the Stackless
website as the
official "Stackless Python 2.8". If you consider Stackless as
official ;-) .

This compiler change is currently the only deviation from CPython 2.7,
but we may support a few easy back-ports on customer demand. We
don'd add
any random stuff, of course.

My question is if that is safe to do:
Can I rely on PEP 404 that the "Python 2.8" namespace never will clash
with CPython?

And if not, what do you suggest then?
It will be submitted by end of November, thanks for your quick
responses!

all the best -- Chris

-- 
Christian Tismer :^)   >
Software Consulting  : Have a break! Take a ride on
Python's
Karl-Liebknecht-Str. 121 :*Starship*
http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776   fax +49
(30) 700143-0023 
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3
BF04
  whom do you want to sponsor today? http://www.stackless.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/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/tismer%40stackless.com



--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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 0404 and VS 2010

[Paul Moore]

On 20 November 2013 22:04, Christian Tismer  wrote:
> My question is not answered at all, sorry Joao!
> I did not ask a teacher for his opinion on Stackless, but the community
> about the
> validity of pep 404.
>
> I don't want a python 2.7 that does not install correctly, because people
> don't read instructions. And exactly that will happen if I submit a modified
> python 2.7 to PyPI.
>
> This is a topic on Stackless Python, and I am asking python-dev before I do
> it.
> But people know this has its limits.

PEP 404 says there will be no Python 2.8. In my view, If you release
something named (Stackless) Python 2.8, that seems to me to be pretty
unfriendly given python-dev's clear intentions. Call it Stackless
Python 2.7 plus for Visual Studio 2010 if you want, but using the
version number 2.8 is bound to confuse at least some newcomers about
the status of the Python 2.x line, and that's what PEP 404 was
intended to avoid.

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 428 - pathlib - ready for approval

[Antoine Pitrou]

On Wed, 20 Nov 2013 13:42:42 -0800
Guido van Rossum  wrote:
> On Tue, Nov 19, 2013 at 1:04 PM, Antoine Pitrou  wrote:
> 
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form.  Here is the last call for any comments or
> > arguments against approval, before Guido marks the PEP accepted (or
> > changes his mind :-)).
> >
> 
> Congrats Antoine! I've approved your PEP. Go ahead with the integration.
> 
> Everybody: pathlib is an immediately useful standard way for manipulating
> file paths, both platform-specific and platform-independent (so you can
> work with Windows paths on a POSIX system and vice versa).
> 
> pathlib  won't replace os.path immediately (the current status is
> "provisional", which means that the API may still be tweaked after 3.4 is
> released), but in the long term I expect os.path to die a quiet death (as
> well as the host of 3rd party path modules that preceded pathlib).
> 
> Great job Antoine!

I've posted the implementation at http://bugs.python.org/issue19673
I know you've already more or less reviewed it, so I'm gonna commit in
the coming days anyway :)

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 0404 and VS 2010

[Barry Warsaw]

On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:

>Many customers are forced to stick with Python 2.X because of other products,
>but they require a Python 2.X version which can be compiled using Visual
>Studio 2010 or better.  This is considered an improvement and not a bug fix,
>where I disagree.

I'm not so sure about that.  Python 2.7 can still get patches to help extend
its useful life by allowing it to be built with newer compiler suites.  I
believe this has already been done for various Linux compilers.  I see no
non-technical reason why Python 2.7 can't be taught how to build with VS 2010
or newer.  Details are subject to RM approval, IMHO.

>I have created a very clean Python 2.7.6+ based CPython with the Stackless
>additions, that compiles with VS 2010, using the adapted project structure
>of Python 3.3.X, and I want to publish that on the Stackless website as the
>official "Stackless Python 2.8". If you consider Stackless as official ;-) .
>
>This compiler change is currently the only deviation from CPython 2.7,
>but we may support a few easy back-ports on customer demand. We don'd add
>any random stuff, of course.

I think you're just going to confuse everyone if you call it "Stackless Python
2.8" and it will do more harm than good.

Cheers,
-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] Accepting PEP 3154 for 3.4?

[Tim Peters]

[Tim]
>> BTW, I'm not a web guy:  in what way is HTTP chunked transfer mode
>> viewed as being flawed?  Everything I ever read about it seemed to
>> think it was A Good Idea.

[Martin]
> It just didn't work for some time, see e.g.
>
> http://bugs.python.org/issue1486335
> http://bugs.python.org/issue1966
> http://bugs.python.org/issue1312980
> http://bugs.python.org/issue3761
>
> It's not that the protocol was underspecified - just the implementation
> was "brittle" (if I understand that word correctly).

"Easily broken in catastrophic ways" is close, like a chunk of peanut
brittle can shatter into a gazillion pieces if you drop it on the
floor.

http://en.wikipedia.org/wiki/Brittle_(food)

Or like the infinite loops in some of the bug reports, "just because"
some server screwed up the protocol a little at EOF.

But for pickling there are a lot fewer picklers than HTML transport
creators ;-)  So I'm not much worried about that.  Another of the bug
reports amounted just to that urllib, at first, didn't support chunked
transfer mode at all.

> And I believe (and agree with you) that the cause for this "difficult
> to implement" property is that the framing is in putting framing "in the 
> middle"
> of the stack (i.e. not really *below* pickle itself, but into pickle
> but below the opcodes - just like http chunked transfer is "in" http,
> but below the content encoding).

It's certainly messy that way.  But doable, and I expect the people
working on it are more than capable enough to get it right, by at
latest the 4th try ;-)
___
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 428 - pathlib - ready for approval

[Mark Lawrence]

On 20/11/2013 22:01, Antoine Pitrou wrote:


pathlib imports many modules at startup, so for scripts for which
startup time is critical using os.path may still be the best option.



Will there be or is there a note to this effect in the docs?

--
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

___
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 0404 and VS 2010

[Chris Barker]

On Wed, Nov 20, 2013 at 12:52 PM, Christian Tismer wrote:

> according to pep 404, there will never be an official Python 2.8.
> The migration path is from 2.7 to 3.x.
>
> I agree with this strategy in almost all consequences but this one:
>
> Many customers are forced to stick with Python 2.X because of other
> products, but they require a Python 2.X version which can be compiled
> using Visual Studio 2010 or better.
> This is considered an improvement and not a bug fix, where I disagree.
>

maybe we need to continue that discussion then -- and call this a bug fix.

It seems clear to me that the Python X.Y version number specifies a set of
features and their implementation, not a particular build with a particular
compiler. So a python 2.7 build with VS2010 (or any other compiler for that
matter) is still python 2.7.

And for what it's worth, stackless aside  I'd love to see a python2.7
binary built with a newer MS compiler -- for instance, the latest pyton
plugin for Visual Studio lets you debug python and C extensions side by
side -- very cool, and only available with VS2012.

Sorry I'm out of the loop, but are there patched required to use newer VS
compilers to build 2.7? or is this really just a matter of what the
official python org builds are build with?

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] [issue19494] Problems with HTTPBasicAuthHandler

[Matej Cepl]

Hello,

I am trying to work on fixing issue 19494 (HTTPBasicAuthHandler 
doesn't work with Github and other websites which require prior 
Authorization header in the first request).


I have created this testing script calling GitHub v3 API using 
new “authentication handlers” (they are subclasses of 
HTTPSHandler, not HTTPBasicAuthHandler) and hoped that when 
I manage to make this script working, I could rewrite it into 
patch against cpython code.


However, when I run this script I get this error (using 
python3-3.3.2-8.el7.x86_64)


matej@wycliff: $ python3 test_create_1.py 
DEBUG::gh_url = https://api.github.com/repos/mcepl/odt2rst/issues/

DEBUG::req = 
DEBUG::req.type = https
DEBUG:http_request:type = https
Traceback (most recent call last):
 File "test_create_1.py", line 80, in 
   handler = opener.open(req, json.dumps(create_data).encode('utf8'))
 File "/usr/lib64/python3.3/urllib/request.py", line 475, in open
   response = meth(req, response)
 File "/usr/lib64/python3.3/urllib/request.py", line 587, in http_response
   'http', request, response, code, msg, hdrs)
 File "/usr/lib64/python3.3/urllib/request.py", line 513, in error
   return self._call_chain(*args)
 File "/usr/lib64/python3.3/urllib/request.py", line 447, in _call_chain
   result = func(*args)
 File "/usr/lib64/python3.3/urllib/request.py", line 595, in http_error_default
   raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 401: Unauthorized
matej@wycliff: $ 

Could anybody suggest what I am doing wrong? I guess I need to 
somehow include into opener original HTTPBasicAuthHandler (for 
error handlers). Any ideas how to do it?


Best,

Matěj Cepl

--
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

- Do you think of yourself as a Christian artist?
- I'm an artist who is a Christian. I'm not a Christian artist.
 -- Johny Cash
in his last interview

===
import base64
import http.client
import urllib.request
import json
import os
import logging
from configparser import ConfigParser
logging.basicConfig(format='%(levelname)s:%(funcName)s:%(message)s',
   level=logging.DEBUG)


class HTTPBasicPriorAuthHandler(urllib.request.HTTPHandler):
   handler_order = 400

   def __init__(self, *args, **kwargs):
   passwd_mgr = kwargs.pop('password_mgr', None)
   urllib.request.HTTPHandler.__init__(self, *args, **kwargs)
   self.passwd = passwd_mgr

   def http_request(self, req):
   logging.debug("type = {}".format(req.type))
   if not req.has_header('Authorization'):
   user, passwd = self.passwd.find_user_password(
   None, req.get_full_url())
   auth_str = base64.standard_b64encode(
   '{}:{}'.format(user, passwd).encode('ascii'))
   req.add_header('Authorization',
  'Basic {}'.format(auth_str))
   return urllib.request.AbstractHTTPHandler.do_request_(self, req)

if hasattr(http.client, 'ssl'):
   handler_order = 400

   class HTTPSBasicPriorAuthHandler(urllib.request.HTTPSHandler):
   def __init__(self, *args, **kwargs):
   passwd_mgr = kwargs.pop('password_mgr', None)
   urllib.request.HTTPSHandler.__init__(self, *args, **kwargs)
   self.passwd = passwd_mgr

   https_request = HTTPBasicPriorAuthHandler.http_request


cp = ConfigParser()
cp.read(os.path.expanduser('~/.githubrc'))

# That configuration file should look something like
# [github]
# user=mylogin
# password=myveryverysecretpassword

gh_user = cp.get('github', 'user')
gh_passw = cp.get('github', 'password')
repo = 'odt2rst'

pwd_manager = urllib.request.HTTPPasswordMgrWithDefaultRealm()
pwd_manager.add_password(None, uri='https://api.github.com', user=gh_user,
passwd=gh_passw)
auth_prior_handler = HTTPSBasicPriorAuthHandler(password_mgr=pwd_manager)
auth_prior_handler.set_http_debuglevel(2)

auth_handler = urllib.request.HTTPBasicAuthHandler(password_mgr=pwd_manager)

opener = urllib.request.build_opener(auth_prior_handler, auth_handler)

API_URL = "https://api.github.com/repos/{0}/{1}/issues/";
gh_url = API_URL.format(gh_user, repo, 1)

logging.debug("gh_url = {0}".format(gh_url))
req = urllib.request.Request(gh_url)
logging.debug('req = {}'.format(req))
logging.debug('req.type = {}'.format(req.type))

create_data = {
   'title': 'Testing bug summary',
   'body': '''This is a testing bug. I am writing here this stuff,
   just to have some text for body.''',
   'labels': ['BEbug']
}

handler = opener.open(req, json.dumps(create_data).encode('utf8'))

print(handler.getcode())
print(handler)


pgpRhuWjF9c2P.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/optio

Re: [Python-Dev] PEP 0404 and VS 2010

[Christian Tismer]

Hey Barry,

On 20.11.13 23:30, Barry Warsaw wrote:

On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:


Many customers are forced to stick with Python 2.X because of other products,
but they require a Python 2.X version which can be compiled using Visual
Studio 2010 or better.  This is considered an improvement and not a bug fix,
where I disagree.

I'm not so sure about that.  Python 2.7 can still get patches to help extend
its useful life by allowing it to be built with newer compiler suites.  I
believe this has already been done for various Linux compilers.  I see no
non-technical reason why Python 2.7 can't be taught how to build with VS 2010
or newer.  Details are subject to RM approval, IMHO.


I have created a very clean Python 2.7.6+ based CPython with the Stackless
additions, that compiles with VS 2010, using the adapted project structure
of Python 3.3.X, and I want to publish that on the Stackless website as the
official "Stackless Python 2.8". If you consider Stackless as official ;-) .

This compiler change is currently the only deviation from CPython 2.7,
but we may support a few easy back-ports on customer demand. We don'd add
any random stuff, of course.

I think you're just going to confuse everyone if you call it "Stackless Python
2.8" and it will do more harm than good.


Barry, that's a good thing! This way I have a chance to get my build in 
at all.

And that's the question, after re-thinking:

Where can I check my change in, if it is going to be accepted as a valid
2.7 bug fix (concerning VS 2008 as a bug, that is is)?

I was intending to do this since a year but was stopped by MVL's influence.
Maybe this needs to be re-thought, since I think different.

What I do not know:
Should I simply check this in to a python 2.7.x-VS2010 branch?
Or what do you suggest, then?

In any case, my question still stands, and I will do something with the
Stackless branch by end of November. Please influence me ASAP, I don't
intend to do any harm, but that problem is caused simply by my existence,
and I want to stick with that for another few decades.

If I think something must be done, then I have my way to do it.
If you have good reasons to prevent this, then you should speak up in the
next 10 days, or it will happen. Is that ok with you?

Hugs -- your friend Chris

--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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 0404 and VS 2010

[Terry Reedy]

On 11/20/2013 5:30 PM, Barry Warsaw wrote:

On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:


Many customers are forced to stick with Python 2.X because of other products,
but they require a Python 2.X version which can be compiled using Visual
Studio 2010 or better.  This is considered an improvement and not a bug fix,
where I disagree.


I'm not so sure about that.  Python 2.7 can still get patches to help extend
its useful life by allowing it to be built with newer compiler suites.  I
believe this has already been done for various Linux compilers.  I see no
non-technical reason why Python 2.7 can't be taught how to build with VS 2010
or newer.  Details are subject to RM approval, IMHO.


With the availability of the free 2008 express edition being 
problematical, I would really like to see this.



I have created a very clean Python 2.7.6+ based CPython with the Stackless
additions, that compiles with VS 2010, using the adapted project structure
of Python 3.3.X, and I want to publish that on the Stackless website as the
official "Stackless Python 2.8". If you consider Stackless as official ;-) .


A compiler change is not a language change and does not need merit a new 
language version number. Anyway I believe that using 'Python 2.8' would 
be illegal without PSF approval. From

http://www.python.org/psf/trademarks/
'"Python" is a registered trademark of the PSF.'
(PSF Tracemarks Committee, psf-tradema...@python.org)

The core developers determine the meaning of 'Python x.y' and we have 
determined that there shall be no 'Python 2.8'. Or if you prefer, we 
have defined it to be the empty language ;-).



This compiler change is currently the only deviation from CPython 2.7,


It is not a deviation from 'Python 2.7'. The compiler used by the PSF 
*CPython* distribution is an implementation detail. For all I know, 
other distributors, such as ActiveState, already distribute 2.7 compiled 
with other compilers. Your new Stackless would still run Python 2.7.



but we may support a few easy back-ports on customer demand. We don'd add
any random stuff, of course.


I suspect that you (or your customers) will not be the only people who 
want selected 3.x features without the 3.0 shift to unicode text and who 
do not care about the 3.3 improvement of the unicode implementation. But 
such hybrid mixtures are not 'Python x.y'. If you make such mixtures on 
a private customer by customer basis, then no public name is needed.



I think you're just going to confuse everyone if you call it "Stackless Python
2.8" and it will do more harm than good.


Avoiding confusion is the purpose of registering trademarks.

--
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 0404 and VS 2010

[Antoine Pitrou]

On Wed, 20 Nov 2013 17:30:44 -0500
Barry Warsaw  wrote:
> On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:
> 
> >Many customers are forced to stick with Python 2.X because of other products,
> >but they require a Python 2.X version which can be compiled using Visual
> >Studio 2010 or better.  This is considered an improvement and not a bug fix,
> >where I disagree.
> 
> I'm not so sure about that.  Python 2.7 can still get patches to help extend
> its useful life by allowing it to be built with newer compiler suites.  I
> believe this has already been done for various Linux compilers.  I see no
> non-technical reason why Python 2.7 can't be taught how to build with VS 2010
> or newer.  Details are subject to RM approval, IMHO.

I think it isn't only about teaching it to build with VS 2010, but
providing binaries compatible with the VS 2010 runtime.
Otherwise, AFAIU, if extensions are built with VS 2010 but loader with
a VS 2008-compiled Python, there will be ABI problems.

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 0404 and VS 2010

[Christian Tismer]

Yes Paul,

On 20.11.13 23:15, Paul Moore wrote:

On 20 November 2013 22:04, Christian Tismer  wrote:

My question is not answered at all, sorry Joao!
I did not ask a teacher for his opinion on Stackless, but the community
about the
validity of pep 404.

I don't want a python 2.7 that does not install correctly, because people
don't read instructions. And exactly that will happen if I submit a modified
python 2.7 to PyPI.

This is a topic on Stackless Python, and I am asking python-dev before I do
it.
But people know this has its limits.

PEP 404 says there will be no Python 2.8. In my view, If you release
something named (Stackless) Python 2.8, that seems to me to be pretty
unfriendly given python-dev's clear intentions. Call it Stackless
Python 2.7 plus for Visual Studio 2010 if you want, but using the
version number 2.8 is bound to confuse at least some newcomers about
the status of the Python 2.x line, and that's what PEP 404 was
intended to avoid.


I see what you intend, but I am not convinced what's best.

Building a version that is numbered the same as existing versions, but
binary incompatible is IMHO much more confusing that a version 2.8
which clearly says "if you are not 2.8, then you are not compatible".

I am addressing Windows users, and they usually click a version,
and if it doesn't work, they complain.

The reason to go this way _was_ simplicity, moving to an impossible
version, that justifies itself by that impossibility. They would have to
install a whole series of packages, which they all would get from my
site, and it works.

And to repeat: Stackless Python is a slightly different, very compatible 
version,

that has never got approval about being official or compatible.
The reason that I am asking is to minimize the friction that I had to
envision, anyway. It is your chance to minimize that friction by giving
me good reasons to re-think my decision.

But it will happen, soon, in the one or the other way. So please don't 
think I

am begging for something - I am offering something, but it will happen.

Best regards -- Chris

--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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] Accepting PEP 3154 for 3.4?

[Antoine Pitrou]

Hello,

I have made two last-minute changes to the PEP:

- addition of the FRAME opcode, as discussed with Tim, and keeping a
  fixed 8-byte frame size

- addition of the MEMOIZE opcode, courtesy of Alexandre, which replaces
  PUT opcodes in protocol 4 and helps shrink the size of pickles

If there's no further opposition, I'd like to mark this PEP accepted
(or let someone else do it) in 24 hours, so that the implementation can
be integrated before Sunday.

Regards

Antoine.


On Sat, 16 Nov 2013 19:15:26 +0100
Antoine Pitrou  wrote:
> 
> Hello,
> 
> Alexandre Vassalotti (thanks a lot!) has recently finalized his work on
> the PEP 3154 implementation - pickle protocol 4.
> 
> I think it would be good to get the PEP and the implementation accepted
> for 3.4. As far as I can say, this has been a low-controvery proposal,
> and it brings fairly obvious improvements to the table (which table?).
> I still need some kind of BDFL or BDFL delegate to do that, though --
> unless I am allowed to mark my own PEP accepted :-)
> 
> (I've asked Tim, specifically, for comments, since he contributed a lot
> to previous versions of the pickle protocol.)
> 
> The PEP is at http://www.python.org/dev/peps/pep-3154/ (should be
> rebuilt soon by the server, I'd say)
> 
> Alexandre's implementation is tracked at
> http://bugs.python.org/issue17810
> 
> 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] Accepting PEP 3154 for 3.4?

[Tim Peters]

[Antoine]
> I have made two last-minute changes to the PEP:
>
> - addition of the FRAME opcode, as discussed with Tim, and keeping a
>   fixed 8-byte frame size

Cool!


> - addition of the MEMOIZE opcode, courtesy of Alexandre, which replaces
>   PUT opcodes in protocol 4 and helps shrink the size of pickles

Long overdue - clever idea!


> If there's no further opposition, I'd like to mark this PEP accepted
> (or let someone else do it) in 24 hours, so that the implementation can
> be integrated before Sunday.

I think Guido already spoke on this - but, if he didn't, I will.  Accepted :-)
___
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 428 - pathlib - ready for approval

[Chris Barker]

On Wed, Nov 20, 2013 at 1:39 PM, Giampaolo Rodola' wrote:

> Isn't this redundant?
>
> >>> Path.cwd()
> PosixPath('/home/antoine/pathlib')
>
> Probably this is just personal taste but I'd prefer the more explicit:
>
> >>> Path(os.getcwd())
> PosixPath('/home/antoine/pathlib')
>
> I understand all the os.* replication (Path.rename, Path.stat etc.) but
> all these methods assume you're dealing with an instantiated Path instance
> whereas Path.cwd is the only one which doesn't.
>

That's a standard pattern for using a classmethod as an alternate
constructor -- similar to:

datetime.now()
dict.fromkeys()
etc

and it can really reduce namespace clutter (do you really want to import
both os and path for this? (OK, you way well be importing os anyway, but...)

It also allows you to get that functionality in a subclass.

Anyway, it's not that different, and I like it ;-)

Other than that the module looks absolutely awesome and a big improvement
> over os.path!
>

indeed -- thanks for moving this forward, it is a long time coming!

By the way, for us dinosaurs  is this going to exactly match the
pathlib implementation that can be used with py2?

-Chris

>

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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 428 - pathlib - ready for approval

[Antoine Pitrou]

On Wed, 20 Nov 2013 14:43:26 -0800
Chris Barker  wrote:
> 
> By the way, for us dinosaurs  is this going to exactly match the
> pathlib implementation that can be used with py2?

pathlib up to 0.8 (on PyPI) has a different API - since there were so
many changes done as part of the release process.

When pathlib-in-the-stdlib stabilizes, I plan to release a pathlib 1.0
on PyPI that will integrate the PEP's API.

In the meantime, if you don't mind installing from VCS, you clone the
Mercurial repo (https://bitbucket.org/pitrou/pathlib/) and then
checkout branch "pep428".  It's 2.7-compatible.

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] Accepting PEP 3154 for 3.4?

[Antoine Pitrou]

On Wed, 20 Nov 2013 18:45:53 -0600
Tim Peters  wrote:
> [Antoine]
> > I have made two last-minute changes to the PEP:
> >
> > - addition of the FRAME opcode, as discussed with Tim, and keeping a
> >   fixed 8-byte frame size
> 
> Cool!
> 
> 
> > - addition of the MEMOIZE opcode, courtesy of Alexandre, which replaces
> >   PUT opcodes in protocol 4 and helps shrink the size of pickles
> 
> Long overdue - clever idea!
> 
> 
> > If there's no further opposition, I'd like to mark this PEP accepted
> > (or let someone else do it) in 24 hours, so that the implementation can
> > be integrated before Sunday.
> 
> I think Guido already spoke on this - but, if he didn't, I will.  Accepted :-)

Thank you! I have marked it accepted then.
(with a final nit - EMPTY_FROZENSET isn't necessary and is gone)

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 428 - pathlib - ready for approval

[Antoine Pitrou]

On Thu, 21 Nov 2013 01:51:59 +0100
Antoine Pitrou  wrote:
> On Wed, 20 Nov 2013 14:43:26 -0800
> Chris Barker  wrote:
> > 
> > By the way, for us dinosaurs  is this going to exactly match the
> > pathlib implementation that can be used with py2?
> 
> pathlib up to 0.8 (on PyPI) has a different API - since there were so
> many changes done as part of the release process.

Make that "PEP process", sorry.

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] Accepting PEP 3154 for 3.4?

[Guido van Rossum]

Yup. Agreed. Ship it!


On Wed, Nov 20, 2013 at 4:54 PM, Antoine Pitrou  wrote:

> On Wed, 20 Nov 2013 18:45:53 -0600
> Tim Peters  wrote:
> > [Antoine]
> > > I have made two last-minute changes to the PEP:
> > >
> > > - addition of the FRAME opcode, as discussed with Tim, and keeping a
> > >   fixed 8-byte frame size
> >
> > Cool!
> >
> >
> > > - addition of the MEMOIZE opcode, courtesy of Alexandre, which replaces
> > >   PUT opcodes in protocol 4 and helps shrink the size of pickles
> >
> > Long overdue - clever idea!
> >
> >
> > > If there's no further opposition, I'd like to mark this PEP accepted
> > > (or let someone else do it) in 24 hours, so that the implementation can
> > > be integrated before Sunday.
> >
> > I think Guido already spoke on this - but, if he didn't, I will.
>  Accepted :-)
>
> Thank you! I have marked it accepted then.
> (with a final nit - EMPTY_FROZENSET isn't necessary and is gone)
>
> 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/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] Accepting PEP 3154 for 3.4?

[Tim Peters]

[Alexandre Vassalotti]
> Looking at the different options available to us:
>
> 1A. Mandatory framing
>   (+) Allows the internal buffering layer of the Unpickler to rely
>   on the presence of framing to simplify its implementation.
>   (-) Forces all implementations of pickle to include support for
>   framing if they want to use the new protocol.
>   (-) Cannot be removed from future versions of the Unpickler
>   without breaking protocols which mandates framing.
> 1B. Optional framing
>   (+) Could allow optimizations to disable framing if beneficial
>   (e.g., when pickling to and unpickling from a string).

Or to slash the size of small pickles (an 8-byte size field can be
more than half the total pickle size).


> 2A. With explicit FRAME opcode
>   (+) Makes optional framing simpler to implement.
>   (+) Makes variable-length encoding of the frame size simpler
>   to implement.
>   (+) Makes framing visible to pickletools.

(+) Adds (a little) redundancy for sanity checking.

>   (-) Adds an extra byte of overhead to each frames.
> 2B. No opcode
>
> 3A. With fixed 8-bytes headers
>  (+) Is simple to implement
>  (-) Adds overhead to small pickles.
> 3B. With variable-length headers
>  (-) Requires Pickler implemention to do extra data copies when
>  pickling to strings.
>
> 4A. Framing baked-in the pickle protocol
>  (+) Enables faster implementations
> 4B. Framing through a specialized I/O buffering layer
>  (+) Could be reused by other modules
>
> I may change my mind as I work on the implementation, but at least for now,
> I think the combination of 1B, 2A, 3A, 4A will be a reasonable compromise
> here.

At this time I'd make the same choices, so don't expect an argument
from me ;-)  Thank you!
___
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 428 - pathlib - ready for approval

[Chris Barker - NOAA Federal]

On Nov 20, 2013, at 4:53 PM, Antoine Pitrou  wrote:

>
> When pathlib-in-the-stdlib stabilizes, I plan to release a pathlib 1.0
> on PyPI that will integrate the PEP's API.

Great, thanks!

Chris



> In the meantime, if you don't mind installing from VCS, you clone the
> Mercurial repo (https://bitbucket.org/pitrou/pathlib/) and then
> checkout branch "pep428".  It's 2.7-compatible.
>
> 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/chris.barker%40noaa.gov
___
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 0404 and VS 2010

[MRAB]

On 20/11/2013 23:36, Christian Tismer wrote:

Hey Barry,

On 20.11.13 23:30, Barry Warsaw wrote:

On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:


Many customers are forced to stick with Python 2.X because of other products,
but they require a Python 2.X version which can be compiled using Visual
Studio 2010 or better.  This is considered an improvement and not a bug fix,
where I disagree.

I'm not so sure about that.  Python 2.7 can still get patches to help extend
its useful life by allowing it to be built with newer compiler suites.  I
believe this has already been done for various Linux compilers.  I see no
non-technical reason why Python 2.7 can't be taught how to build with VS 2010
or newer.  Details are subject to RM approval, IMHO.


I have created a very clean Python 2.7.6+ based CPython with the Stackless
additions, that compiles with VS 2010, using the adapted project structure
of Python 3.3.X, and I want to publish that on the Stackless website as the
official "Stackless Python 2.8". If you consider Stackless as official ;-) .

This compiler change is currently the only deviation from CPython 2.7,
but we may support a few easy back-ports on customer demand. We don'd add
any random stuff, of course.

I think you're just going to confuse everyone if you call it "Stackless Python
2.8" and it will do more harm than good.


Barry, that's a good thing! This way I have a chance to get my build in
at all.
And that's the question, after re-thinking:

Where can I check my change in, if it is going to be accepted as a valid
2.7 bug fix (concerning VS 2008 as a bug, that is is)?

I was intending to do this since a year but was stopped by MVL's influence.
Maybe this needs to be re-thought, since I think different.

What I do not know:
Should I simply check this in to a python 2.7.x-VS2010 branch?
Or what do you suggest, then?

In any case, my question still stands, and I will do something with the
Stackless branch by end of November. Please influence me ASAP, I don't
intend to do any harm, but that problem is caused simply by my existence,
and I want to stick with that for another few decades.

If I think something must be done, then I have my way to do it.
If you have good reasons to prevent this, then you should speak up in the
next 10 days, or it will happen. Is that ok with you?

Hugs -- your friend Chris


You could call it "Spython" instead!

___
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 0404 and VS 2010

[Brian Curtin]

On Wed, Nov 20, 2013 at 5:36 PM, Christian Tismer  wrote:
> Hey Barry,
>
>
> On 20.11.13 23:30, Barry Warsaw wrote:
>>
>> On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:
>>
>>> Many customers are forced to stick with Python 2.X because of other
>>> products,
>>> but they require a Python 2.X version which can be compiled using Visual
>>> Studio 2010 or better.  This is considered an improvement and not a bug
>>> fix,
>>> where I disagree.
>>
>> I'm not so sure about that.  Python 2.7 can still get patches to help
>> extend
>> its useful life by allowing it to be built with newer compiler suites.  I
>> believe this has already been done for various Linux compilers.  I see no
>> non-technical reason why Python 2.7 can't be taught how to build with VS
>> 2010
>> or newer.  Details are subject to RM approval, IMHO.
>>
>>> I have created a very clean Python 2.7.6+ based CPython with the
>>> Stackless
>>> additions, that compiles with VS 2010, using the adapted project
>>> structure
>>> of Python 3.3.X, and I want to publish that on the Stackless website as
>>> the
>>> official "Stackless Python 2.8". If you consider Stackless as official
>>> ;-) .
>>>
>>> This compiler change is currently the only deviation from CPython 2.7,
>>> but we may support a few easy back-ports on customer demand. We don'd add
>>> any random stuff, of course.
>>
>> I think you're just going to confuse everyone if you call it "Stackless
>> Python
>> 2.8" and it will do more harm than good.
>
>
> Barry, that's a good thing! This way I have a chance to get my build in at
> all.
> And that's the question, after re-thinking:
>
> Where can I check my change in, if it is going to be accepted as a valid
> 2.7 bug fix (concerning VS 2008 as a bug, that is is)?

If you do end up checking something in, I think it should be a
backport of the 3.x VS2010 work, rather than contributing your own
patch starting from 2.7. Otherwise any differences in the way you did
things could cause pain while merging changes between the branches.
___
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 0404 and VS 2010

[Nick Coghlan]

On 21 Nov 2013 10:33, "Antoine Pitrou"  wrote:
>
> On Wed, 20 Nov 2013 17:30:44 -0500
> Barry Warsaw  wrote:
> > On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:
> >
> > >Many customers are forced to stick with Python 2.X because of other
products,
> > >but they require a Python 2.X version which can be compiled using
Visual
> > >Studio 2010 or better.  This is considered an improvement and not a
bug fix,
> > >where I disagree.
> >
> > I'm not so sure about that.  Python 2.7 can still get patches to help
extend
> > its useful life by allowing it to be built with newer compiler suites.
 I
> > believe this has already been done for various Linux compilers.  I see
no
> > non-technical reason why Python 2.7 can't be taught how to build with
VS 2010
> > or newer.  Details are subject to RM approval, IMHO.
>
> I think it isn't only about teaching it to build with VS 2010, but
> providing binaries compatible with the VS 2010 runtime.
> Otherwise, AFAIU, if extensions are built with VS 2010 but loader with
> a VS 2008-compiled Python, there will be ABI problems.

Right, this is the problem - building with newer compilers isn't an issue,
changing the Windows ABI *is* (which is the reason Christian is proposing a
version bump to denote the ABI incompatibility).

If Visual Studio Express 2010 and later can be told to build against the
VS2008 C runtime, then that is something that can (and probably should) be
enabled in the next CPython 2.7 maintenance release (for both the main
build process and for distutils extension building).

Doing a 2.8 release *just* to change the Windows ABI to a new version of
the MS C runtime, on the other hand, seems impossible to do without
thoroughly confusing people (regardless of whether it's CPython or
Stackless making such a change).

I'd certainly want to explore all our alternatives with the Microsoft folks
for getting our preferred option (new compiler, old C runtime) working in
an open source friendly way before we went down the path of a 2.x ABI bump.

I've cc'ed Steve Dower directly, as he's the best person I know to ask
about this kind of problem.

Cheers,
Nick.

>
> 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/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 0404 and VS 2010

[Nick Coghlan]

Another alternative I'd prefer to an ABI version bump: backporting the "C
runtime independence" aspects of the stable ABI to Python 2.7.

There are only a relatively small number of APIs that lead to the
requirement for consistent C runtimes, so allowing those to be excluded at
compile time would make it possible to ensure extensions can be built
safely under VS2010 with the newer C runtime.

Cheers,
Nick.
___
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