On 30 September 2015 at 16:57, Chris Barker - NOAA Federal
wrote:
>> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1)
>> 2. Work from an SDK command prompt (with the environment variables
>> set, and the SDK on PATH).
>> 3. Set DISTUTILS_USE_SDK=1
>> 4. Done.
>
> This, unfortunat
On 30 September 2015 at 20:15, Paul Moore wrote:
> I'll push an addition to packaging.python.org, probably tomorrow.
https://github.com/pypa/python-packaging-user-guide/pull/175
Unless there's a discussion on the PR, I'll probably commit it in
On 1 October 2015 at 18:18, Chris Barker wrote:
>> If you want a simple "install a
>> Python build environment" process, you could look at
>> https://github.com/pfmoore/pybuild -
>
> nice! I'll checdk that out. But I"m confused -- right in there, you write:
>
> "setting up a Windows build environm
On 22 October 2015 at 10:21, Gregory P. Smith wrote:
> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum wrote:
>>
>> Well the whole point is not to have to figure out how to implement that
>> right now.
>>
>> On Wed, Oct 21, 2015 at 6:45 PM, Random832 wrote:
>>>
>>> Guido van Rossum writes:
>>>
On 29 October 2015 at 17:36, Donald Stufft wrote:
> On October 29, 2015 at 1:32:31 PM, Nathaniel Smith (n...@pobox.com) wrote:
>> > (I know saying that last part out loud will probably just cause
>> someone to pop out of the woodwork and explain how shadowing the
>> sys module is a great idea and
On 29 October 2015 at 18:46, Laura Creighton wrote:
> In a message of Thu, 29 Oct 2015 18:27:59 +0000, Paul Moore writes:
>>The idle issues seem to me to demonstrate that shadowing the stdlib is
>>a bad idea. Of course, consenting adults, and if you override you're
>>
On 29 October 2015 at 18:45, Donald Stufft wrote:
> So I don=E2=80=99t think it=E2=80=99s true that people don=E2=80=99t shad=
> ow the standard library, they just have various ways to do it that have s=
> everal gotchas and require people to generally hack around the limitation=
> .=C2=A0
(Your
On 11 November 2015 at 15:13, Christophe Bal wrote:
> Hello.
>
> I'm a french teacher and I would like to use Python with young child but
> I've a big problem. All the keyword are in english. So I would like to know
> if there is a way to hack the AST tools such as to use french keywords and
> the
On 15 November 2015 at 07:23, Stephen J. Turnbull wrote:
> I don't see any good reason for allowing non-ASCII-compatible
> encodings in the reference CPython interpreter.
>From PEP 263:
Any encoding which allows processing the first two lines in the
way indicated above is allowed a
On 15 November 2015 at 16:40, Stephen J. Turnbull wrote:
> What PEP 263 did do was to specify that non-ASCII-compatible encodings
> are not supported by the PEP 263 mechanism for declaring the encoding
> of a Python source program. That's because it looks for a "magic
> number" which is the ASCII
On 18 November 2015 at 15:57, Hrvoje Niksic wrote:
> If this never really worked in Python, feel free to drop the issue. I may be
> misremembering the language in which scripts I saw using this techniques
> years ago were written - most likely sh or Perl.
It was Perl. In the past I've tried to em
On 24 November 2015 at 03:46, Nick Coghlan wrote:
> I think there are three relevant categories here:
>
> 1. Folks who assume that "https" means the same thing in Python that
> it means in web browsers, and are currently experiencing a silent
> security failure
> 2. Folks who already know it doesn
On 24 November 2015 at 13:20, Nick Coghlan wrote:
> I believe you're referring mainly to the original PEP 476 change there. In
> the context of PEP 493, this is another group that would potentially benefit
> from the suggested "security downgrade" environment variable (if any
> redistributors deci
On 24 November 2015 at 14:27, Laura Creighton wrote:
> In a message of Tue, 24 Nov 2015 14:05:53 +0000, Paul Moore writes:
>>Simply adding "people who have no control over their broken
>>infrastructure" with a note that this PEP helps them, would be
>>sufficient he
On 24 November 2015 at 17:16, Toshio Kuratomi wrote:
> The long term answer for such environments is to update their internal
> certificate management to at least match the standards set by the public
> internet, but in the meantime, it is desirable to offer these administrators
> a way to c
On 24 November 2015 at 18:37, Toshio Kuratomi wrote:
> I don't quite agree with this but it's probably moot in the face of
> the previous and certain cornercases. Self-signed certs work just
> fine with the backports to python-2.7.9+ but you have to add the ca to
> the clients. An organization t
On 3 December 2015 at 12:51, Laura Creighton wrote:
> Intentional or Oversight?
Hard to find :-)
https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries
I went via "Atoms" in the expression section, then followed the links
in the actual grammar spec.
Paul
On 3 December 2015 at 14:26, Laura Creighton wrote:
> Am I missing something important about the 'display' language?
It's a term that's used in the lisp and/or functional programming
communities, I believe. And I think I recollect that something similar
is used in (mathematical) set theory So it'
On 21 January 2016 at 17:18, Brett Cannon wrote:
> It's live: https://docs.python.org/devguide/#status-of-python-branches
Nice :-)
Minor nit, the status column says "end of life", but the text below
the table uses the term "end of line" (as does the comment "Versions
older than 2.6 reached their
On 27 January 2016 at 05:23, Sjoerd Job Postmus wrote:
> On Mon, Jan 25, 2016 at 11:58:12PM +0100, Victor Stinner wrote:
>> ...
>> Oh, they are a lot of things to do! ...
>
> Just wondering, do you also need a set of (abusive) test-cases which
> check 100% conformity to the CPython semantics? I'm
On 3 February 2016 at 09:50, Glenn Linderman wrote:
> On 2/3/2016 12:15 AM, Alexander Walters wrote:
>
>> On a very personal note (like the rest of this wasn't my personal issues
>> with possibly making my life slightly more difficult), I would much rather
>> see python stop touching the registry
On 3 February 2016 at 16:46, Steve Dower wrote:
> So a few high-level observations:
>
> * any program can install anywhere on the machine and make its libraries
> available to a specific version of Python by creating a subkey under
> 'PythonCore\x.y\PythonPath'
Yeah, that's horrid but not reall
On 3 February 2016 at 17:04, Steve Dower wrote:
> Rest of the email is spelling out how to create the scenario above, since I
> assume people won't believe it :)
>
> 1. Take Python 3.4.1, install it (Just for Me), zip up the stdlib into
> python34.zip and copy the binaries and zip to a "portable"
On 3 February 2016 at 16:29, Steve Dower wrote:
> Final point I want to reiterate - Python itself is essentially registry free
> already in that it does not need registry settings to function.
That's something we should probably publicise better. People seem
unaware of it (in much the same way th
On 3 February 2016 at 19:20, Alexander Walters wrote:
> Uh its C:\Anaconda[2]\ for anyone running the installer with the
> privileges to edit the registry... (It wont ask to elevate unless you
> install for all users, and that's where all users will install). So on that
> point alone, this sa
On 8 February 2016 at 14:32, Victor Stinner wrote:
> Since 3.3, functions of the os module started to emit
> DeprecationWarning when called with bytes filenames.
Everywhere? Or just on Windows? I can't tell from your email and I
don't have a Unix system to hand to check.
> The rationale is quite
On 9 February 2016 at 01:57, Chris Barker - NOAA Federal
wrote:OTOH, it's a
> All I can say is "ouch". Hard to call it a regression to no longer
> allow this mess..
OTOH, it's a major regression for someone using an 8-bit codepage that
doesn't have these problems. Code that worked fine for them n
On 9 February 2016 at 10:13, Victor Stinner wrote:
> IMHO we have to put a line somewhere between Python 2 and Python 3.
> For some specific use cases, there is no good solution which works on
> both Python versions.
>
> For filenames, there is no simple design on Python 2. bytes is the
> natural
On 10 February 2016 at 08:00, Stephen J. Turnbull wrote:
>> The earlier issue was that that doesn't work (e.g. a bytes path
> > from os.scandir couldn't be passed back into open()).
>
> My purely-from-the-user-side take is that that's just a bug in
> os.scandir that should be fixed, and that even
On 10 February 2016 at 08:45, Victor Stinner wrote:
> 2016-02-10 9:30 GMT+01:00 Paul Moore :
>> Whether removing the bytes interface is feasible, given that there's
>> then no way that works across Python 2 and 3 of writing code that
>> manipulates the sort of bytes-t
On 10 February 2016 at 22:20, Georg Brandl wrote:
> This came up in python-ideas, and has met mostly positive comments,
> although the exact syntax rules are up for discussion.
+1 on the PEP. Is there any value in allowing underscores in strings
passed to the Decimal constructor as well? The same
On 10 February 2016 at 23:14, Steven D'Aprano wrote:
> On Wed, Feb 10, 2016 at 10:53:09PM +0000, Paul Moore wrote:
>> On 10 February 2016 at 22:20, Georg Brandl wrote:
>> > This came up in python-ideas, and has met mostly positive comments,
>> > although t
On 12 February 2016 at 00:16, Steven D'Aprano wrote:
> I think that there is broad agreement that:
>
> - the basic idea is sound
> - leading underscores followed by digits are currently legal
> identifiers and this will not change
> - underscores should not follow the sign - +
> - underscores sh
On 12 February 2016 at 20:06, Chris Barker wrote:
> As Paul said, as long as I can do the above, I'll be fine, but I think
> everyone's source code will be a lot cleaner in the long run if you don't
> have the option of doing who knows what weird arrangement
Just to be clear, I'm personally i
On 17 February 2016 at 23:26, Dave Hirschfeld wrote:
> I've run into issue 25939 (https://bugs.python.org/issue25939) when trying
> to deploy a python webapp with IIS on Windows. This issue is preventing us
> from deploying the app to production as the workaround AFAICT requires
> running the app
On 1 March 2016 at 11:37, David Cournapeau wrote:
> I am not clear about 3., especially on what should be changed. I know that
> for 2.7, we need to change PC\getpathp.c for sys.path, but are there any
> other places where the registry is used by python itself ?
My understanding from the earlier
On 6 April 2016 at 06:00, Guido van Rossum wrote:
> On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman wrote:
>> [...] we can't do:
>>
>> app_root = Path(...)
>> config = app_root/'settings.cfg'
>> with open(config) as blah:
>> # whatever
>>
>> It feels like instead of addressing th
On 6 April 2016 at 00:45, Guido van Rossum wrote:
> This does sound like it's the crucial issue, and it is worth writing
> up clearly the pros and cons. Let's draft those lists in a thread
> (this one's fine) and then add them to the PEP. We can then decide to:
>
> - keep the status quo
> - change
On 6 April 2016 at 19:32, Brett Cannon wrote:
>> > Now we need clear details. :) Some open questions are:
>> >
>> > 1. Name: __path__, __fspath__, or something else?
>>
>> __fspath__
>
> +1 for __path__, +0 for __fspath__ (I don't know how widespread the notion
> that "fs" means "file system" is)
On 6 April 2016 at 20:39, Brett Cannon wrote:
>> I'm a little confused by this. To support the older pathlib, they have
>> to do patharg = str(patharg), because *none* of the proposed
>> attributes (path or __path__) will exist.
>>
>> The getattr trick is needed to support the *new* pathlib, when
On 6 April 2016 at 23:46, Brett Cannon wrote:
> str(path) will definitely work, path.__path__ will work if you're running
> the next set of bugfix releases. fspath(path) will only work in Python 3.6
> and newer.
Ah, that was something I hadn't appreciated, that the builtin would be
3.6+ whereas t
On 7 April 2016 at 11:48, Nikolaus Rath wrote:
> Why is:
>
> path = getattr(obj, '__fspath__') if hasattr(obj, '__fspath__') else obj
>
> better than
>
> path = str(obj) if isinstance(obj, pathlib.Path) else obj
One reason is that the former doesn't need you to import pathlib,
which is good if yo
On 7 April 2016 at 15:40, Eric Snow wrote:
> On Apr 6, 2016 11:11 PM, "Raymond Hettinger"
> wrote:
>> Having worked through the API when it is first released, I find it to be
>> highly forgettable (i.e. I have to re-read the docs each time I've revisited
>> it).
>
> Agreed, though it's arguably b
On 8 April 2016 at 15:18, Jon Ribbens wrote:
> I would be very interested to see if anyone can manage to break it.
> Bugs which are trivially fixable are of course welcomed, but the real
> question is: is this approach basically sound, or is it fundamentally
> unworkable?
What are the limitations
On 10 April 2016 at 08:36, Nick Coghlan wrote:
> In addition to the existing "str(pathobj)", a "path" property was
> recently added for that purpose:
>
>>>> import pathlib
>>>> pathlib.PureWindowsPath(".")
>PureWindowsPath('.')
>>>> pathlib.PureWindowsPath(".").path
>'.'
>
> (T
On 10 April 2016 at 15:07, Sven R. Kunze wrote:
> If there's some agreement to change things with respect to those 5 points, I
> am willing to put some time into it.
In broad terms I agree with these points. Thanks for doing the
research. It would certainly be good to try to improve pathlib based
On 11 April 2016 at 15:46, Jon Ribbens wrote:
> It's trying to alter
> the global Python environment so that arbitrary code can be executed,
> whereas I am not even trying to allow execution of arbitrary code and
> am not altering the global environment.
However, it's not at all clear (to me at l
On 11 April 2016 at 17:53, Jon Ribbens wrote:
>> You're limiting the subset of Python that people can use,
>> understood. And you're trying to ensure that people can't do "bad
>> things". Again, understood. But what subset are you actually allowing,
>> and what things are you trying to protect aga
On 12 April 2016 at 06:28, Stephen J. Turnbull wrote:
> Donald Stufft writes:
>
> > I think yes and yes [__fspath__ and fspath should be allowed to
> > handle bytes, otherwise] it seems like making it needlessly harder
> > to deal with a bytes path
>
> It's not needless. This kind of polymorph
On 11 April 2016 at 22:21, Sven R. Kunze wrote:
> On 11.04.2016 23:08, Random832 wrote:
>>
>> On Mon, Apr 11, 2016, at 17:04, Sven R. Kunze wrote:
>>>
>>> PS: The only way out that I can imagine is to fix pathlib. I am not in
>>> favor of fixing functions of "os" and "os.path" to except "path"
>>>
On 13 April 2016 at 14:51, Nick Coghlan wrote:
> The potentially SE-strings only come back when you pass str, and the
> operating system data isn't properly encoded according to the nominal
> filesystem encoding. They round trip nicely to other operating system
> APIs, but can indeed be a problem
On 13 April 2016 at 17:18, Fred Drake wrote:
> Names like os.fspath() and os.fssyspath() seem good to me.
-1 on fssyspath - the "system" representation is bytes on POSIX, but
not on Windows. Let's be explicit and go with fsbytespath().
But agreed that always-constant boolean parameters are a bad
On 13 April 2016 at 17:31, Ethan Furman wrote:
> On 04/13/2016 09:27 AM, Paul Moore wrote:
>>
>> On 13 April 2016 at 17:18, Fred Drake wrote:
>
>
>>> Names like os.fspath() and os.fssyspath() seem good to me.
>>
>>
>> -1 on fssyspath - the "sy
On 14 April 2016 at 08:02, Stephen J. Turnbull wrote:
> So let me propose what I think is the elephant in the room. If you're
> going to have a polymorphic __fspath__, then pathlib is *the* example
> of a module that *desperately* needs to be polymorphic. Consider:
>
> A non-text Application
On 14 April 2016 at 17:46, Ethan Furman wrote:
> On 04/14/2016 08:59 AM, Michael Mysinger via Python-Dev wrote:
>
>> I am saying that if os.path.join now accepts RichPath objects, and those
>> objects can return either str or bytes, then its much harder to reason
>> about
>> when I have all bytes
On 15 April 2016 at 10:35, Victor Stinner wrote:
> 2016-04-15 11:21 GMT+02:00 Steven D'Aprano :
>> This isn't just a question about the secrets module. PEP 399 suggests
>> than any C classes/functions should have a pure Python version as
>> fallback, but compare_digest doesn't. I don't know whethe
On 16 April 2016 at 12:21, Stephen J. Turnbull wrote:
> OK, you win, __fspath__ needs to be polymorphic.
>
> But you've just shifted me to -1 on "os.fspath": it's an attractive
> nuisance. EIBTI, applications and high-level library functions should
> use os.fsdecode or os.fsencode.
I presume you
On 16 April 2016 at 14:46, Stephen J. Turnbull wrote:
> Paul Moore writes:
[...]
> > 1. I just want to pass the argument on to other functions - just do
> > so, stdlib functions will work fine.
>
> I think this is a bad idea unless you *need* polymorphism, but OK,
>
On 25 April 2016 at 23:55, Franklin? Lee wrote:
> FWIW, Gmail's policies require:
[...]
> That link is currently the only obvious way to unsubscribe.
I'm not sure why gmail's policies should apply to this list.
I'm not against having an easy reminder of how to unsubscribe, but the
clickable link
On 13 May 2016 at 17:06, Sven R. Kunze wrote:
> As far as I remember, one goal of this proposal was to avoid wallet gardens.
> During the lengthy discussion on python-ideas people brought up that some
> third-party libs indeed subclass from str. They are currently locked out.
Hardly. Libraries th
On 13 May 2016 at 17:57, Ethan Furman wrote:
> 1) What is a wallet garden?
I assumed he meant "walled garden" (for people who don't know the
phrase, it refers to an area or capability that's only made accessible
to "favoured" clients - think of something like Apple's App Store,
where you have to
On 24 May 2016 at 15:11, Koos Zevenhoven wrote:
>> Please, no. We learned that lesson in Python 2.2.1 with True/False.
>
> What happened? True was included in 2.2.1 but not False?-). Anyway, I
> guess you are probably right, and "3.6->" is the way to go. Besides,
> Guido already wrote that in the
On 21 October 2013 11:59, R. David Murray wrote:
> On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman wrote:
>> On 10/20/2013 07:42 PM, Raymond Hettinger wrote:
>> >
>> > In short, I recommend that efforts be directed at improving help() rather
>> > than limiting introspection by way of less clean
On 15 November 2013 06:48, Tim Peters wrote:
> Is that a feature? Or an accident? It's very surprising to find a
> non-empty match inside an empty match (the outermost lookahead
> assertion).
Personally, I would read (?=(R))" as finding an empty match at a point
where R starts. There's no impli
On 15 November 2013 12:07, Victor Stinner wrote:
>> A new API for binary transforms is potentially an academically
>> interesting concept, but it solves zero current real world problems.
>
> I would like to reply the same for these codecs: they are not solving
> any real world problem :-)
As Nick
On 18 November 2013 10:18, Tim Golden wrote:
>> Should nturl2path be renamed to windowsurl2path? Should os.name return
>> "windows" on Windows, and should sysconfig support "windows" scheme name?
>
> I think the answer's fairly obviously "no" for reasons of backwards
> compatibility. (Although tha
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 re
On 21 November 2013 11:15, wrote:
> Whether this would be a good idea or not, I don't know. It would create
> separate ecosystems for different releases of Python 2.7 for different
> CRTs. Package authors would have to create multiple binary releases of
> the same modules for Windows, and upload
On 21 November 2013 21:02, Greg Ewing wrote:
> Is that much different from package authors having to
> release binaries for different versions of Python,
> if they want to support older versions?
>
> Having multiple binaries for the same x.y version
> is different from what's been done before, but
On 21 November 2013 21:27, Chris Barker wrote:
> That's already the unstated case. But besides stackless, it some of us are
> advocating that there be python.org-provided binaries built with a newer
> compiler (eventually, anyway).
I see no problem with python.org producing and distributing a
VS2
On 25 November 2013 03:18, Ben Hoyt wrote:
> d_ino -- can a non-Windows dev tell me how or when d_ino would be
> useful? If it's useful, is it useful in a higher-level, cross-platform
> API such as scandir()?
OK, so I'm a Windows dev, but my understanding is that d_ino is useful
to tell if two fi
On 26 November 2013 18:16, Eli Bendersky wrote:
> FWIW I'm not advocating a breaking behavior change here - I fully realize
> the ship has sailed. I'm interested in mitigation actions, though. Making
> the documentation explain this explicitly + adding an option to disable
> prefix matching (in 3.
On 31 December 2013 05:31, Dan Stromberg wrote:
> So far the results are looking good for 3.x.
Where can the results be seen?
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https:
On 6 January 2014 15:29, Bob Hanson wrote:
> At any rate, the attempts to connect to the network seem like
> undesirable behavior to this man. If pip is necessary, then some
> Window users may well end up without it -- and then not know why
> something later doesn't work.
I have installed python
On 7 January 2014 09:40, Georg Brandl wrote:
> Very nice, thanks. If I was to make a blasphemous suggestion I would
> even target it for Python 3.4. (No, seriously, this is a big issue
> - see the recent discussion by Armin - and the big names involved show
> that it is a major holdup of 3.x upt
On 9 January 2014 09:01, Mark Shannon wrote:
> On 09/01/14 00:07, Ben Finney wrote:
>>
>> Kristján Valur Jónsson writes:
>>
>>> Believe it or not, sometimes you really don't care about encodings.
>>> Sometimes you just want to parse text files.
>>
>>
>> Files don't contain text, they contain byte
On 9 January 2014 10:15, Kristján Valur Jónsson wrote:
> Also, the problem I'm describing has to do with real world stuff.
> This is the python 2 program:
> with open(fn1) as f1:
> with open(fn2, 'w') as f2:
> f2.write(process_text(f1.read())
>
> Moving to python 3, I found that this q
On 9 January 2014 13:00, Kristján Valur Jónsson wrote:
>> You don't say what problems, but I assume encoding/decoding errors. So the
>> files apparently weren't in the system encoding. OK, at that point I'd
>> probably say to heck with it and use latin-1. Assuming I was sure that (a)
>> I'd
>> ne
On 9 January 2014 22:00, Chris Barker wrote:
> On Thu, Jan 9, 2014 at 1:45 PM, Antoine Pitrou wrote:
>>
>> > latin-1 guaranteed to work with any binary data, and round-trip
>> > accurately?
>>
>> Yes, it is.
>>
>> > and will surrogateescape work for arbitrary binary data?
>>
>> Yes, it will.
>
>
On 9 January 2014 22:08, Ethan Furman wrote:
> For example: b'\x01\x00\xd1\x80\xd1\83\xd0\x80'
>
> If that were decoded using latin1 how would I then get the first two bytes
> to the integer 256 and the last six bytes to their Cyrillic meaning?
> (Apologies for not testing myself, short on time.)
On 10 January 2014 12:19, M.-A. Lemburg wrote:
> Just a word of caution:
>
> Using the 'latin-1' to mean unknown encoding can easily result
> in Mojibake (unreadable text) entering your application with
> dangerous effects on your other text data.
Agreed. The latin-1 suggestion is purely for peop
On 12 January 2014 01:01, Victor Stinner wrote:
> Supporting formating integers would allow to write b"Content-Length:
> %s\r\n" % 123, which would work on Python 2 and Python 3.
I'm surprised that no-one is mentioning b"Content-Length: %s\r\n" %
str(123) which works on Python 2 and 3, is explici
On 12 January 2014 09:23, Georg Brandl wrote:
>> On 12 January 2014 01:01, Victor Stinner wrote:
>>> Supporting formating integers would allow to write b"Content-Length:
>>> %s\r\n" % 123, which would work on Python 2 and Python 3.
>>
>> I'm surprised that no-one is mentioning b"Content-Length: %
On 12 January 2014 16:52, Kristján Valur Jónsson wrote:
> I mean, basically what I am suggesting is that in addition to %b with
>
> def helper(o):
> return str(o).encode('ascii', 'strict')
>
> b'foo%bbar'%(helper(myobj), )
>
> you have
>
> b'foo%sbar'%(myobj, )
But that's not what the current
On 12 January 2014 17:03, Ethan Furman wrote:
> We know full well the difference between unicode and bytes, and we know full
> well that numbers and much of the text we need has an ASCII (bytes!)
> representation. When we do a b'Content Length: %d' % len(binary_data) we
> are expecting to get bac
On 12 January 2014 18:26, Ethan Furman wrote:
> True enough! ;) It's unacceptable in the sense that the bytes type is
> /almost/ there, it's /almost/ what is needed to handle the boundary
> conditions. We have a __bytes__ method (how is it supposed to be used?)
> that could be made to fit the i
On 12 January 2014 19:30, Emile van Sebille wrote:
> len(open('chars','wb').write("".join(map (chr,range(256.read())
Python 2:
>>> len(open('chars','wb').write("".join(map (chr,range(256.read())
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'NoneType' object h
On 12 January 2014 22:10, Greg Ewing wrote:
> I think the readability argument becomes a bit sharper when
> you consider more complex examples, e.g. if I have a tuple
> of 3 floats that I want to put into a PDF file, then
>
>b"%f %f %f" % my_floats
>
> is considerably clearer than
>
>b" ".
On 13 January 2014 18:58, Guido van Rossum wrote:
> I hear the objections against b'%s' % 'x' returning b"'x'" loud and
> clear, and if the noise about that sub-issue is preventing folks from
> seeing the absurdity in PEP 460, we can talk about a compromise, e.g.
> use %b which would require its a
On 17 January 2014 15:50, Eric V. Smith wrote:
> For #3, hopefully this "additional work" on the 3.x side would just be
> to add, to each class where you already have a custom __format__ used
> for b''.format(), code like:
>
> def __format_ascii__(self, fmt):
> return self.__format__(f
On 22 January 2014 10:30, Donald Stufft wrote:
> Python 3.4 has made great strides in making it easier for applications
> to simply turn on these settings, however many people are not aware
> at all that they need to opt into this. Most assume that it will operate
> similarly to their browser, cur
On 22 January 2014 11:29, Donald Stufft wrote:
>> 1. To be "like the browser" we'd need to use the OS certificate store,
>> which isn't the case on Windows at the moment (managing those
>> certificate bundle files is most definitely *not* "like the browser" -
>> I'd have no idea how to add a self-
On 22 January 2014 12:02, Donald Stufft wrote:
>> We also have to account for the fact that an awful lot of Python
>> applications are corporate ones relying on perimeter defence for
>> security, or private CAs, or just self-signed certificates that their
>> users have already accepted. There are
On 22 January 2014 13:55, Donald Stufft wrote:
>
> As an additional side note, anecdotal evidence and what not, but
> *every* time I bring this up somewhere I get at least one reply that
> looks similar to https://twitter.com/ojiidotch/status/425986619879866368
Surprise that Python doesn't verify
On 22 January 2014 13:29, Christian Heimes wrote:
> Side note:
> Users can simple add self-signed certs to OpenSSL's cert store and get
> validation for free. It's possible to do that with an environment
> variable, too. But I recommend against the environment variable because
> you may overwrite
On 27 January 2014 15:35, Victor Stinner wrote:
> Version 2 is the fastest in Python 3.3 and 3.4, but version 4 with
> Python 3.4 produces the smallest file.
Which version is used when creating pyc files? This benchmark might
suggest that version 2 is the best...
Paul
___
On 2 February 2014 02:11, Terry Reedy wrote:
>> example, sum({1: 100, 2: 200}) returns 3. If one wanted to reserve the
>> opportunity to handle mappings specifically in the future, without being
>> locked in by backwards-compatibility, how should one handle it?
>>
>> a) document that behaviour wit
On 3 February 2014 16:10, Phil Thompson wrote:
> That doesn't answer my original question, that just works around the use
> case I presented.
>
> To restate...
>
> Why is a Latin-1 string considered inconsistent just because it doesn't
> happen to contain any characters in the range 128-255?
Butt
On 12 February 2014 20:38, Nick Coghlan wrote:
>> It *does* seem that Python and Windows is becoming a sadder story
>> -- I know, use Linux. :-)
>
> Actually, we've been substantially improving the Windows integration to make
> things easier for new users, which is the main reason the Windows inst
Can someone please take a look at http://bugs.python.org/issue20621
for me? It appears that there is a significant problem with zipimport
in 3.3.4. It's causing breakage in virtualenv but I've isolated the
issue to what I think is Python itself.
Basically, until this bug is fixed, virtualenv won't
401 - 500 of 1862 matches
Mail list logo
