On Sun, May 24, 2015 at 4:40 AM, Tal Einat wrote:
> > I filed http://bugs.python.org/issue24270 to track this, but there's a
> > fair bit of work to be done to integrate the changes into the existing
> > math module's code, tests and documentation.
>
> Done. Patch attached to the issue. Awaiting
On Sun, May 24, 2015 at 10:00 AM, Tal Einat wrote:
> On Sun, May 24, 2015 at 6:40 PM, Chris Barker
> wrote:
> > What do folks think about adding one to cmath as well, while we are at
> it?
> > It should be pretty straightforward -- I could focus what time I have to
> d
I don't think I have permissions to comment on the issue,so I'm posting
here. If there is a way for me to post to the issue, someone let me know...
In the issue (http://bugs.python.org/issue24270) Tal wrote
"""
I have a question regarding complex values. The code (f
e`` if the values *a* and *b* are close to each other and
``False`` otherwise.
need a space between "each" and "other"
But it all looks good otherwise -- thanks!
-Chris
On Sun, May 24, 2015 at 9:53 PM, Chris Barker wrote:
> I don't think I have permissions to co
On Thu, May 28, 2015 at 9:23 AM, Chris Barker wrote:
> Barry Warsaw wrote:
> >> I do think single-file executables are an important piece to Python's
> >> long-term
> competitiveness.
>
> Really? It seems to me that desktop development is dying. What are th
I'm confused:
Doesn't py2exe (optionally) create a single file executable?
And py2app on the Mac creates an application bundle, but that is
more-or-less the equivalent on OS-X (you may not even be able to have a
single file executable that can access the Window Manager, for instance)
Depending o
sure would be nice
if the API between a) b), and c) could be unified so we could mix and
match different implementations.
And, of course, if cPython itself could be built in a way that makes
step(c) easier/less kludgy great!
-Chris
On Thu, May 28, 2015 at 9:54 AM, Donald Stufft wro
On Thu, May 28, 2015 at 12:25 PM, Sturla Molden
wrote:
> Many Unix tools need Python, so Mac OS X (like Linux distros and FreeBSD)
> will always need a system Python. Yes, it would be great if could be called
> spython or something else than python. But the main problem is that it is
> used by en
28, 2015 11:23:57 AM CDT, Chris Barker
> wrote:
>
>> I'm confused:
>>
>> Doesn't py2exe (optionally) create a single file executable?
>>
>> And py2app on the Mac creates an application bundle, but that is
>> more-or-less the equivalent on OS-X (yo
Getting lost as to what thread this belongs in...
But another tack to take toward a single executable is Cython's embedding
option:
https://github.com/cython/cython/wiki/EmbeddingCython
This is a quick and dirty way to create a C executable that will then run
the cythonized code, all linked to t
On Fri, May 29, 2015 at 7:23 AM, Paul Sokolovsky wrote:
> > An example of a product that does this is Chef, they install their
> > own Ruby and everything but libc into /opt/chef to completely isolate
> > themselves from the host system.
this sounds a bit like what conda does -- install minico
On Mon, Jul 27, 2015 at 11:55 AM, Terry Reedy wrote:
> I think using the word 'naive' is both inaccurate and a mistake.
>
> 'Naive' means simple, primitive, or deficient in informed judgement. It is
> easy to take it as connoting 'wrong'.
In this context "naive" means "having no knowledge of
On Mon, Jul 27, 2015 at 12:07 PM, Chris Angelico wrote:
> > - A minute is exactly 60 seconds.
>
> No leap second support, presumably. Also feature?
>
Leap seconds come in when you convert to a Calendar representation -- a
minute is 60 seconds, always -- even when passing over a leap second.
-CH
On Mon, Jul 27, 2015 at 12:47 PM, Ethan Furman wrote:
> To me, Paul's example is a datetime operation: you start with a datetime
>>> (7am today), perform arithmetic on it by adding a period of time (one
>>> day), and get a datetime as the result (7am tomorrow).
>>>
>>
>> Well, OK, let's propose t
> The only other thing I found
> > really weird about datetime is how Python 2 had no implementation of
> > a UTC tzinfo class, despite this being utterly trivial -
Huh? it is either so trivial that there is no point -- simiply say that
your datetimes are UTC, and you are done.
Or it's not the l
On Mon, Jul 27, 2015 at 2:10 PM, Tim Peters wrote:
> Guido will never allow any aspect of "leap seconds" into the core,
>
really? that is a shame (and odd) -- it's a trick, because we don't know
what leap seconds will be needed in the future, but other than that, it's
not really any different t
Travis,
I'm sure you appreciate that this might all look a bit scary, given the
recent discussion about numpy governance.
But it's an open-source project, and I, at least, fully understand that
going through a big process is NOT the way to get a new idea tried out and
implemented. So I think thin
And in mingw-w64, the only way to select a non-default CRT
>
what is a "default" CRT in this case??
> CRT issues are indeed tricky, because they only bite in certain
> circumstances -- so long as you never pass a FILE* or a fileno across the
> dll boundary, or call malloc in one module and free i
On Wed, Sep 30, 2015 at 12:15 PM, Paul Moore wrote:
> > This, unfortunately is non-trivial, and really a pain if you want to
> > automate builds.
>
> Please clarify.
First point -- that was intended to be a lament, not a criticism. And
certainly not a criticism of anything Python devs are doing
I don't know that anyone disagrees with my point, but, less than an hour
ago, this on the wxPython list:
"""
Microsoft no longer sells the compiler that's needed to build Python 3.4,
and the needed compiler for Python 3.5 is free.
"""
To be fair, if you are trying to build wxWidgets, you may well
On Tue, Oct 6, 2015 at 3:43 PM, Ben Finney
wrote:
>
> > There was peripherally mention of a 4-year-document called LPTHW that
> > recommends 2. I have no idea what they are referring to.
>
> It is expanded in passing, but for reference they are talking about
> “Learn Python the Hard Way” http://l
On Wed, Oct 14, 2015 at 3:04 PM, Laura Creighton wrote:
> That code writers in the scientific python world mostly
> never think of Decimal users, doesn't mean they don't end up writing
> perfectly wonderful tools and libraries we use. :) thankfully :)
>
sure -- but those are almost guaranteed
On Sun, Dec 20, 2015 at 2:28 PM, Chris Angelico wrote:
>
> Would there be value in changing the repr to use keyword arguments?
>
this thread got long, but it sounds like that won't be worth the backwards
compatibility...
> Worse, help(datetime.timedelta) in 3.6 doesn't document the
> construct
On Mon, Feb 8, 2016 at 6:32 AM, Victor Stinner
wrote:
> Windows native type for filenames is
> Unicode, and the Windows has a weird behaviour when you use bytes.
Just to clarify -- what does it currently do for bytes? IIUC, Windows uses
UTF-16, so can you pass in UTF-16 bytes? Or when using by
On Mon, Feb 8, 2016 at 1:51 PM, Victor Stinner
wrote:
> I didn't know. I just checked. It's assert used with a non-empty tuple:
>
> >>> assert ("tuple",)
>
which is more interesting with a tuple without the parentheses:
t = In [*4*]: t = True,
In [*5*]: t
Out[*5*]: (True,)
works fine, but no
On Mon, Feb 8, 2016 at 3:48 PM, MRAB wrote:
> help('assert')
>
> You'll see that in "assert (True,)", the tuple (an object) is the first
> condition (and probably a mistake), whereas in "assert True,", the True is
> the condition and the second expression (after the comma) is missing.
yes,
On Fri, Feb 12, 2016 at 1:00 AM, Paul Moore wrote:
>
> I have no opinion on anything other than that whatever syntax is
> implemented as long as it allows single underscores between digits,
> such as
>
> 1_000_000
>
> Everything else is irrelevant to me, and if I read code that uses
> anything el
On Wed, Apr 6, 2016 at 5:57 PM, Ethan Furman wrote:
> But not a big deal. I think this is pretty much for occasional use by
>
> library authors, so not a big deal what it is named.
>>
>
> It's mostly for the stdlib itself. I imagine that most libraries would
> just take what they are given and p
On Thu, Apr 7, 2016 at 3:50 AM, Michel Desmoulin
wrote:
>
> Path objects don't have splitext()
that is useful -- let's add it. (and others if need be)
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point
On Thu, Apr 7, 2016 at 12:00 AM, INADA Naoki wrote:
>
> I feel adding protocol only for path is bit over engineering. So I'm -0.5
> on adding __fspath__.
>
> I'm +1 on adding general protocol for *coerce to string* like __index__.
>
isn't __str__ the protocol for "coerce to string" ?
__index__
On Thu, Apr 7, 2016 at 4:03 AM, Donald Stufft wrote:
> It seems like it would be reasonable for pathlib.Path to call fspath on the
> path passed to pathlib.Path.__init__, which would mean that if other
> libraries
> implemented __fspath__ then you could pass their path objects to pathlib
> and
>
On Thu, Apr 7, 2016 at 10:02 AM, Antoine Pitrou wrote:
> >> Having worked through the API when it is first released, I find it to
> > be highly forgettable
>
> This is terribly unspecific as far as criticism goes. "Highly
> forgettable" depends on who you ask.
Exactly -- for my part, I need t
On Thu, Apr 7, 2016 at 11:44 AM, Nathaniel Smith wrote:
> No, __index__ is the protocol for "do a safe coerce to integer". The name
> is misleading, but its use in non-indexing contexts is well established.
> E.g.
>
> " ab" * obj
>
> will return a string with obj.__index__() repetitions.
>
A good
On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote:
> On 7 April 2016 at 03:26, Brett Cannon wrote:
>
> > Method or attribute? (changes what kind of one-liner you might use in
> > libraries, but I think historically all protocols have been methods and
> the
> > serialized string representation
On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
> I'm still thinking a little bit about 'pathname', which to me sounds
> more like a string than fspath does [1].
I like that a lot - or even "__pathstr__" or "__pathstring__"
after all, we're making a big deal out of the fact that a path
On Fri, Apr 8, 2016 at 11:13 AM, Ethan Furman wrote:
> So the plausible choices are, I think:
>
> - __fspath__ # File System Path -- possible confusion with Path
>
> - __fsstr__ # File System String
I think we really need "path" in there somewhere
>
> - __fspathstr__ # File System Path
On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven wrote:
> >
> > __pathstr__ # pathstring
> >
>
> Or perhaps __pathstring__ in case it may be or return byte strings.
>
I'm fine with __pathstring__ , but I thought it was already decided that it
would NOT return a bytestring!
-CHB
--
Christoph
one little note:
On Tue, Apr 12, 2016 at 3:41 AM, Paul Moore wrote:
> 4. There are further improvements that could be made to pathlib,
> certainly, but again they are optional, and pathlib is fine without
> them.
>
Exactly -- "improvements to pathlib" and "make the stdlib pathlib
compatible" ar
On Tue, Apr 12, 2016 at 7:54 AM, Sven R. Kunze wrote:
>
> My conclusion is that these changes are not optional and tweaking os, io
> and shutil is just yet another workaround for a clean solution. :)
>
Is the clean solution to re-implement EVERYTHING in the stdlib that
involves a path in a new,
On Mon, Apr 11, 2016 at 10:40 PM, Greg Ewing
wrote:
>
> So the ONLY thing
>> you should do with it is pass it along to another low level system
>> call.
>>
>
> Not quite -- you can separate it into components and
> work with them. Essentially the same set of operations
> that os.path provides.
>
On Tue, Apr 12, 2016 at 8:57 AM, Sven R. Kunze wrote:
> As an example: time.sleep takes a number of seconds (notice the primitive
> datatype just like a string) and does not take timedelta.
>
> Why don't we add datetime.timedelta support to time.sleep? Very same thing.
yup -- and it there were
On Tue, Apr 12, 2016 at 9:20 AM, Chris Angelico wrote:
> > latin1? I thought latin1 had a code point for 0-255, so how could using
> it
> > raise an encoding error?
>
> Latin-1 / ISO-8859-1 defines a character for every byte, so any byte
> string will *decode*. It only defines 256 characters as
On Tue, Apr 12, 2016 at 9:32 AM, Koos Zevenhoven wrote:
> > 1) A "proper" path object -- i.e. pathlib.Path or anything else that
> > supports the path protocol.
> >
> > 2) the bytes that the OS actually needs.
> >
>
> You do have a point there. But since bytes pathnames are deprecated on
> window
Hi folks,
There have been multiple reports of folks having failures on startup of
matplotlib, which appears to be due to the most recent OS-X version setting
the locale weirdly. This was identified last summer in this issue:
http://bugs.python.org/issue18378
It looks like the issue was figured o
so are we worried that __fspath__ will exist and be callable, but might
raise an AttributeError somewhere inside itself? if so isn't it broken
anyway, so should it be ignored?
and I know it's asking poermission rather than forgiveness, but what's
wrong with:
if hasattr(path, "__fspath__"):
p
On Wed, Apr 13, 2016 at 1:47 PM, Random832 wrote:
> On Wed, Apr 13, 2016, at 16:39, Chris Barker wrote:
> > so are we worried that __fspath__ will exist and be callable, but might
> > raise an AttributeError somewhere inside itself? if so isn't it broken
> > anywa
I'm really confused -- you had a handful of very positive responses to
your offer to help with Python on Windows.
Then a couple off the cuff remarks (at least one of which was serious)
about what is often known as "the bus factor":
But I think you may want to take into account the history here.
>
> Fredrik Lundh is also affected (and might not have received any mail,
>> same as me):
>>
>> https://pypi.python.org/pypi/PIL
>>
>>
> He might be, but clearly the Python community as a whole is not impacted.
> From what I see the latest version of PIL that is available is 1.1.6, which
> requir
On Fri, May 6, 2016 at 10:43 AM, Joseph Lee Nunn III
wrote:
> Then I have found the right list to post on, for my problem is a bug in
> the Python 3.5.1 distribution. Albeit one which will only manifest in
> certain situations.
>
> The presence of numerous `-isysroot /Developer/SDKs/MacOSX10.6.s
On Sat, May 7, 2016 at 10:59 PM, Chris Barker wrote:
>
> Trying to decide if I want to go through the hassle of installing an
> old XCode to see if i can replicate the bug the OP is reporting
>
OK, I found this gitHub repo with all the old SDKs:
https://github.com/phracker
Thanks Joseph,
I say this isn't worth pursuing until someone else reports the issue, as I
couldn't replicate it with a "clean" system.
I had the old 10.6 SDK in /Developer/SDKs, it could have been ‘special’ in
> that I did alot of weird things for a former project and I just don’t
> recall.
>
I
On Fri, May 20, 2016 at 11:42 AM, Brett Cannon wrote:
>
> WFM. I'll let 3.4 and 3.5 just stay as they are and make all PEP 519
> changes a 3.6 thing.
>
I'd like to see it in 3.5 if we could do that -- that'll be available for
operational code a lot sooner than 3.6, and it's still in active
maint
On Mon, May 23, 2016 at 10:13 AM, Brett Cannon wrote:
> 3.5 is still getting bugfixes:
> https://docs.python.org/devguide/#status-of-python-branches
>
> As for backporting __fspath__() for pathlib, you can easily write your own
> subclass that adds it. And since the stdlib won't be updated in 3.5
Hi folks,
The standard build of Py3.5 for Windows is built with VS2015 (correct??)
And it includes the runtime dlls it needs.
However, we've found that wxPython wheels for win32 (not sure about win64)
also need:
MSVCP140.DLL
So: wxPython could include that of course, But it looks like it's gett
> [ERROR]: Your autotools build scripts are 200 lines longer than your
> program. Something’s wrong.
> http://kirbyfan64.github.io/
> On May 25, 2016 2:31 PM, "Chris Barker" wrote:
>
>> Hi folks,
>>
>> The standard build of Py3.5 for Windows is built with
On Wed, May 25, 2016 at 1:40 PM, Chris Angelico wrote:
> But why should CPython
> package a runtime that it doesn't use?
Because it IS part of the "standard runtime environment" that cPython is
providing. The cPython Windows builds are built with a particular compiler
that expects a particular
On Thu, May 26, 2016 at 9:53 AM, Chris Angelico wrote:
> > BUT -- Steve Dower seems to have identified that the wonders of dll hell
> > never cease, and this isn't possible anyway. Oh well.
>
> I'm not entirely grasping what's happening here.
me neither :-(
> There are multiple
> versions of
On Fri, May 27, 2016 at 9:35 AM, M.-A. Lemburg wrote:
> > So if ( and that's a big if) it's possible to anticipate what will be
> > in widespread use in a couple years, getting it in now would be a good
> > thing.
>
> You cut away the important part of what I said:
> "The current patch is 1.2MB f
Folks,
(note this is about 2.7 -- sorry, but a lot of us still use that! I
can only assume that in 3.* this is a non-issue)
I just discovered an issue that's been around a long time:
If you create an Exception with a unicode object for the message, the
message can be silently ignored if it can n
On Thu, Nov 14, 2013 at 1:55 PM, Tres Seaver wrote:
> Fixing any bug is "changing behavior"; 2.7 is not frozen for bugfixes.
Thank you.
> The real question is whether third-party code will break when the
> now-empty error messages appear with '?' littered through them?
right -- any bugfix cha
On Thu, Nov 14, 2013 at 1:20 PM, Victor Stinner
>> If you create an Exception with a unicode object for the message, (...)
>
> In Python 2, there are too many similar corner cases. It is impossible
> to fix these bugs without taking the risk of introducing a regression.
Yes, there are -- the auto
On Thu, Nov 14, 2013 at 3:58 PM, Steven D'Aprano wrote:
> It's not a given that the current behaviour *is* a bug.
I'll concede that it's not a bug unless someone said somewhere that
unicode messages should work .. but that's kind of a semantic
argument.
I have to say it's a very odd choice to m
On Fri, Nov 15, 2013 at 9:21 AM, Armin Rigo wrote:
> I figured that even using the traceback.py module and getting
> "Exception: \u1234\u1235\u5321" is rather useless if you tried to
> raise an exception with a message in Thai.
yup.
> I believe this to also be
> a bug, so I opened https://bugs.
On Fri, Nov 15, 2013 at 5:24 AM, "Martin v. Löwis" wrote:
> Procedurally, it's really easy. Ultimately it's up to the release
> manager to decide which changes go into a release and which don't, and
> Benjamin has already voiced an opinion.
Very early in the conversation, though honestly, probab
Folks,
It seems changing anything about how Exception messages are handles is off
the table for 2.7, and a non-issue in 3.*
Is it worth opening an issue on this, just so we can close it as won't fix?
Or is this thread documentation enough?
NOTE about py3: I'm assuming unicode messages are handle
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 beca
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 t
On Thu, Nov 21, 2013 at 1:32 PM, Christian Tismer wrote:
> I am converted to an OS X developer since 2006, but never had ABI
> problems,
> because I use homebrew,
>
Right, different story -- you are supposed to compile everything on the
target system, so everything stays compatible.
but instead
On Thu, Nov 21, 2013 at 1:09 PM, Greg Ewing wrote:
> Concerning the version number, I thought the intention of
> PEP 404 was simply to say that the PSF would not be releasing
> anything called Python 2.8, not to forbid anyone *else*
> from doing so.
>
> Or am I wrong about that?
>
> If I'm right,
On Thu, Nov 21, 2013 at 10:53 AM, Christian Tismer wrote:
> I also think having a 2.8 out there that is exactly the same as 2.7,
>> except that it was built with a different version of a compiler on one
>> particular platform is a very very bad idea.
>>
> This was not my proposal. I was seeking a
On Thu, Nov 21, 2013 at 1:02 PM, Greg Ewing wrote:
> mar...@v.loewis.de wrote:
>
>> Package authors would have to create multiple binary releases of
>> the same modules for Windows, and upload them to PyPI. pip would have
>> to learn to download the right one, depending on what build of Python
>>
On Thu, Nov 21, 2013 at 1:12 PM, Paul Moore wrote:
> None of the currently available binary distribution formats
> distinguish Windows binaries by anything other than minor version. For
> wheels (and I think eggs), this is a showstopper as the name is
> essential metadata (compatibility tags) fo
On Thu, Nov 21, 2013 at 2:53 PM, Nick Coghlan wrote:
> For 2.7.7, I think some combination of the two following ideas would be
> worth pursuing:
>
> - a C runtime independent API flag (set by default on Windows when
> building with a compiler other than VS2008). This would largely be a
> backport
On Mon, Dec 30, 2013 at 11:16 PM, Lennart Regebro wrote:
> Python-dev probably is a bit special.
>
>
Indeed -- I expect it to be totally non-representative of the broader
Python community.
Everyone on python-dev is at least interested in the process of moving
Python forward.
And Py2 is frozen,
This has all gotten a bit complicated because everyone has been thinking in
terms of actual encodings and actual text files. But I think the use-case
here is something different:
A file with a bunch of bytes in it, _some_of which are ascii, and the rest
are other bytes (maybe binary data, maybe no
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.
>
Then maybe this is really a documentation issue, after all.
On Thu, Jan 9, 2014 at 2:54 PM, Paul Moore
> 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 Thu, Jan 9, 2014 at 3:14 PM, Ethan Furman wrote:
> Sorry, I was too short with my example. My use case is binary files, with
> ASCII metadata and binary metadata, as well as ASCII-encoded numeric
> values, binary-coded numeric values, ASCII-encoded boolean values, and
> who-knows-what-(before
On Fri, Jan 10, 2014 at 9:17 AM, Juraj Sukop wrote:
> As you may know, PDF operates over bytes and an integer or floating-point
> number is written down as-is, for example "100" or "1.23".
>
Just to be clear here -- is PDF specifically bytes+ascii?
Or could there be some-other-encoding unicode
On Fri, Jan 10, 2014 at 6:05 AM, Paul Moore wrote:
> > 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 people who object
On Fri, Jan 10, 2014 at 3:40 PM, Juraj Sukop wrote:
> What this all means is that the PDF objects are expressed in ASCII,
> "stream" objects like images and fonts may have a binary part and I never
> saw those UTF+16 strings.
>
hmm -- I wonder if they are out there in the wild, though
> u
On Fri, Jan 10, 2014 at 3:22 PM, Mark Lawrence wrote:
> The correct way is to read the interface specification which tells you
> what should be in the data. Or do people not use interface specifications
> these days, preferring to guess what they've got instead?
>
No one is suggesting guessing (
On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov wrote:
> - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result.
>
please no -- that's the source of a lot of pain in py2 now.
having a failure as a result of the value, rather than the type, of an
object just makes hard-to-test for bugs.
For the record, we've got a pretty good thread (not this good, though!)
over on the numpy list about how to untangle the mess that has resulted
from porting text-file-parsing code to py3 (and the underlying issue with
the 'S' data type in numpy...)
One note from the github issue:
"""
The use of a
I hope you didn't mean to take this off-list:
On Fri, Jan 17, 2014 at 2:06 PM, Neil Schemenauer wrote:
> In gmane.comp.python.devel, you wrote:
> > For the record, we've got a pretty good thread (not this good, though!)
> > over on the numpy list about how to untangle the mess that has resulted
>
On Sun, Jan 19, 2014 at 7:21 AM, Oscar Benjamin
wrote:
> > long as numpy.loadtxt is explicitly documented as only working with
> > latin-1 encoded files (it currently isn't), there's no problem.
>
> Actually there is problem. If it explicitly specified the encoding as
> latin-1 when opening the fi
On Fri, Feb 14, 2014 at 2:42 AM, Nick Coghlan wrote:
> That's the main reason I still occasionally wonder if
> "AlwaysMin" and "AlwaysMax" singletons might make sense, although that
> approach has problems of its own (specifically, it's hard to actually
> use without breaking the clean NULL -> N
On Fri, Feb 14, 2014 at 1:29 AM, Nick Coghlan wrote:
> On 14 February 2014 18:04, Chris Withers wrote:
> >
> > Am I missing something? How can I get this method down to a sane size?
>
> The easiest way is usually to normalise the attributes to a sensible
> numeric value depending on where you wa
On Sun, Mar 2, 2014 at 6:44 PM, Guido van Rossum wrote:
> AFACT, in that message Victor was only talking about allowing Unicode
> filenames.
>
...
> Finally, in most places Python 2.7 *does* handle Unicode filenames just
> fine.
>
I'm a bit confused. In this example:
http://bugs.python.org/iss
On Mon, Mar 10, 2014 at 8:04 AM, Steven D'Aprano wrote:
> If Python 4 is a conservative release, I don't see any reason to bump
> the major version number until after Python 3.9.
and why even then?
> Perhaps we need a long-term schedule?
>
why not:
3.5: August 2015
> 3.6: February 2017
> 3.
On Mon, Mar 10, 2014 at 12:42 PM, Serhiy Storchaka wrote:
> This is just an euphemism for "not in observable future".
>
>
is ANY of the future observable?
Oh right, The Time Machine!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(2
On Tue, Mar 18, 2014 at 1:47 PM, Terry Reedy wrote:
> The wording is typical for slightly indirect sales pitches in English.
>
yeah, it's spam.
> The same non-specific (no language mentioned) message was sent to
> python-list and, I presume, to tens or even hundreds of other lists (with
> lan
On Fri, Mar 28, 2014 at 2:52 PM, Fred Drake wrote:
> On Fri, Mar 28, 2014 at 5:19 PM, Greg Ewing
> wrote:
> > ISO 8601 doesn't seem to define a representation for
> > negative durations, though, so it wouldn't solve the
> > original problem.
>
> Aside from the horribleness of the ISO 8601 notati
On Thu, Apr 10, 2014 at 7:12 PM, Christian Tismer wrote:
> Then I rather often see things like this:
>
> class someclass(object):
> # note that there is no comment about argument destruction...
>
> def __init__(self, **kwargs):
> first_arg = kwargs.pop('option_1', somedefault)
>
On Mon, Apr 14, 2014 at 1:26 PM, Guido van Rossum wrote:
> >> - I'd prefer a name that plays on 2 and 3, not 2 and 8. :-)
>
How about mirg2**3 (pronounced "migrate") ?
;-)
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-695
Ooops,
Forgot "reply all" last time -- here it is again.
On Wed, Apr 23, 2014 at 3:17 PM, Chris Barker wrote:
> On Mon, Apr 21, 2014 at 11:39 PM, Raymond Hettinger <
> raymond.hettin...@gmail.com> wrote:
>
>> In fact, the distinction is extrinsic to their
On Sun, Apr 27, 2014 at 9:40 AM, Barry Warsaw wrote:
> On Apr 26, 2014, at 12:33 AM, Janzert wrote:
>
> >So the one example under discussion is:
> >foo = long_function_name(
> > var_one, var_two,
> > var_three, var_four)
> >
> >and comes from http://legacy.python.org/dev/peps/pep-0008/#indent
On Sun, Apr 27, 2014 at 1:40 PM, Barry Warsaw wrote:
> On Apr 27, 2014, at 12:34 PM, Chris Barker wrote:
> >foo = long_function_name(var_one,
> > var_two,
> >
On Sun, Apr 27, 2014 at 6:34 PM, Steven D'Aprano wrote:
> > I would agree with having at least one example done with one arg per
> line.
>
> Is it really necessary? I think that one-arg-per-line is an obvious
> variation of the existing example.
>
not really -- a lot of folks learn more from foll
On Mon, Apr 28, 2014 at 3:01 PM, Terry Reedy wrote:
> I don't think anyone should write code with variable width fonts,
>>
>
> The problem is that fixed pitch does not work well for even a half-way
> complete unicode font and I don't know that there are any available.
>
...
> Given that PEP8 gen
101 - 200 of 366 matches
Mail list logo
