On Thu, Nov 27, 2014 at 8:57 AM, Isaac Schwabacher
wrote:
>> Can you summarize that in a self-contained form for inclusion in the PEP?
>>
>> (That was a rhetorical question. :-)
>
> Sure. Is it on GitHub? ;D
Thanks Isaac, I've incorporated your edits.
https://raw.githubusercontent.com/Rosuav/Gen
On Fri, Nov 28, 2014 at 8:54 AM, Victor Stinner
wrote:
> def return_value(value):
> if 0:
> yield
> raise Return(value)
This is one known significant backward-incompatibility issue with this
PEP - it'll be difficult to make this work on Python 2.7, where
"return value" would be a
On Fri, Nov 28, 2014 at 8:18 PM, Victor Stinner
wrote:
> 2014-11-28 10:12 GMT+01:00 Greg Ewing :
>> I don't understand. If I'm interpreting PEP 479 correctly, in
>> 'x = yield from foo', a StopIteration raised by foo.__next__()
>> doesn't get turned into a RuntimeError
>
> The Trollius coroutine u
On Sat, Nov 29, 2014 at 12:59 PM, Nathaniel Smith wrote:
> Option 4: Add a new function sys.swap_module_internals, which takes
> two module objects and swaps their __dict__ and other attributes. By
> making the operation a swap instead of an assignment, we avoid the
> lifecycle pitfalls from Optio
On Sun, Nov 30, 2014 at 11:37 AM, Donald Stufft wrote:
> I also don’t know how to do this. When I’m doing multiple things for CPython
> my “branching” strategy is essentially using hg diff to create a patch file
> with my “branch” name (``hg diff > my-branch.patch``), then revert all of my
> chang
On Sun, Nov 30, 2014 at 1:04 PM, Jim J. Jewett wrote:
> I have a strong suspicion that I'm missing something; I have been
> persuaded both directions too often to believe I have a grip on the
> real issue.
>
> So I'm putting out some assumptions; please tell me if I'm wrong, and
> maybe make them
On Sun, Nov 30, 2014 at 4:06 PM, Ben Finney wrote:
> I don't get a vote. So I'm glad there are some within the Python core
> development team that can see the mistakes inherent in depending on
> non-free tools for developing free software.
While this is a laudable view, this kind of extreme stanc
On Sun, Nov 30, 2014 at 8:54 PM, Nick Coghlan wrote:
> On 30 November 2014 at 15:23, Chris Angelico wrote:
>> Python is already using quite a bit of non-free software in its
>> ecosystem. The Windows builds of CPython are made with Microsoft's
>> compiler, and t
On Mon, Dec 1, 2014 at 6:28 AM, Ethan Furman wrote:
> My issues with GitHub range from selfish to philosophical:
>
> - (selfish) I don't want to learn git
This ties in directly with the popularity argument. How many people
are there who know hg and don't know git? How many who know git and
don'
On Sun, Nov 30, 2014 at 7:07 PM, balaji marisetti
wrote:
> Hi,
Hi. This list is for the development *of* Python, not development
*with* Python, so I'm sending this reply also to
python-l...@python.org where it can be better handled. You'll probably
want to subscribe here:
https://mail.python.org
In response to Guido's call for volunteers, I'm offering myself as a
PEP editor. Who is in charge of this kind of thing? Who manages public
key lists etc?
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
d represent a change in policy, so
> others may want to weigh in.
Nobody has weighed in during the subsequent ~2 years, so I'm hoping a
few of y'all could weigh in one way or the other, and thus bring the
issue to a definitive conclusion.
Cheers,
Chris
--
https://github.com/cvrebert
__
On Tue, Dec 2, 2014 at 6:16 PM, Terry Reedy wrote:
> On 12/2/2014 7:07 PM, Chris Rebert wrote:
>>
>> Hi all,
>>
>> I'm seeking to move http://bugs.python.org/issue16329 towards conclusion.
>> Since the discussion on the issue itself seems to have petered
On Sat, Dec 13, 2014 at 4:29 PM, Donald Stufft wrote:
> So that's basically it, lowest common demoniator programming where it's hard
> to
> look at the future and see anything but the same (or similar) language subset
> that I'm currently using. This is especially frustrating when you see other
>
On Sat, Dec 13, 2014 at 5:13 PM, Donald Stufft wrote:
> First of all, it's essentially the route that Python itself took and the side
> effects of that is essentially what is making things less-fun for me to write
> Python. Doing the same to the users of the things I write would make me feel
> bad
be working with the
latest and greatest cool features or not -- but if you do the problem at
this point isn't anything about py3, it's about the fact that many of us
are required to support old versions, period.
-Chris
However I can't really justify for most situations suppor
On 12/16/2014 03:09 AM, Barry Warsaw wrote:
On Dec 16, 2014, at 02:15 PM, Skip Montanaro wrote:
While he doesn't explicitly say so, I got the distinct impression reading
his recent blog post that he supports one source, not forked sources.
I've ported a fair bit of code, both pure-Python and
On Fri, Dec 19, 2014 at 5:39 AM, Guido van Rossum wrote:
>-- Forwarded message --
> From: Victor Stinner
>
> Hi,
>
> Yes, the link is dead. It looks like the following link contains the same
> info:
> https://docs.python.org/devguide/triaging.html
>
> Dead page:
> https://web.arch
On Fri, Dec 19, 2014 at 12:24 PM, Terry Reedy wrote:
> PEP 3 is listed in PEP 0 under Abandoned, Withdrawn, and Rejected PEPs
> If this is proper, it does not make sense to update it.
> If this is not, the header should be updated.
Guido passed the request on to the pep-editors list, which I too
On Thu, Dec 25, 2014 at 2:56 PM, Sky Kok wrote:
> Anyway, sometimes when people review my patches for CPython, they send
> me a notice through Rietveld Code Review Tool which later will send an
> email to me. However, my GMail spam filter is aggressive so the email
> will always be classified as s
On Thu, Jan 1, 2015 at 12:24 PM, Benjamin Peterson wrote:
> On Wed, Dec 31, 2014, at 19:32, Ryan Gonzalez wrote:
>> Not sure if this is something to post here...but...
>>
>> [image: Inline image 1]
>
> That must be some sort of inconsistency in Google's index, since the
> actual page's title is co
On Sun, Jan 4, 2015 at 10:34 AM, Steve Dower wrote:
> http://stevedower.id.au/blog/the-python-3-5-installer/
You talk of installing by default into Program Files, and having a
separate per-user installation mode. How do these two installation
targets interact? Suppose someone installs 3.5 globall
On Mon, Jan 5, 2015 at 9:56 AM, Steve Dower wrote:
> (Windows will always put per-user PATH entries at the end). The py.exe
> launcher handles this best, and the system version will always be found first.
>
> As for versions, 3.5 vs 3.6 should be distinguished explicitly ("py -3.5" vs
> "py -3.6
On Mon, Jan 5, 2015 at 12:20 PM, Steve Dower wrote:
> Unfortunately, Windows enforces the PATH ordering. It constructs the PATH
> from two registry keys, one is the system-wide value (that requires
> administrative privileges to modify) and it is followed by the user's value
> (that does not re
for instance,
may give you just what you need, if you don't want to go the
py2exe/PyInstaller approach (though you probably do want to go that way, as
far as I can tell from your description of your use-case.
I'm inclined to think that this does not belong as part of the stand
ering.
Personally, I'd prefer to see us be explicit about data structures used
when "security matters", an explicit RandomOrderedDict would make that
clear.
cheers,
Chris
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
On Sun, Feb 1, 2015 at 9:13 PM, Benjamin wrote:
> I much prefer the idea of a 'where' keyword to denote typing, as discussed
> http://aroberge.blogspot.com/2015/01/type-hinting-in-python-focus-on.html,
> but I think a refinement of their idea would prove even better:
>
> def retry(callback, timeou
On Fri, Feb 6, 2015 at 10:27 AM, Francis Giraldeau
wrote:
> Instead, I access members directly:
> char *str = PyUnicode_DATA(frame->f_code->co_filename);
> size_t len = PyUnicode_GET_DATA_SIZE(frame->f_code->co_filename);
>
> Is it safe to assume that unicode objects co_filename and co_name are al
On Fri, Feb 13, 2015 at 12:46 PM, MRAB wrote:
class BaseInt:
> ... def __init__(self, value):
> ... self._value = value
> ... def __add__(self, other):
> ... return type(self)(self._value + other)
On Fri, Feb 13, 2015 at 11:55 AM, Guido van Rossum wrote:
> ... there
On Sat, Feb 14, 2015 at 11:07 AM, Nick Coghlan wrote:
> OTOH, it may be time to reconsider our recommendation to distros as well,
> suggesting that for Python 3.5+, we will consider it appropriate to have the
> "python" symlink refer to "python3".
If *all* distros provide a "python2" symlink, the
On Mon, Feb 16, 2015 at 10:47 PM, Petr Viktorin wrote:
>> If *all* distros provide a "python2" symlink, then the recommendation
>> can become "use python if it's 2/3 compatible, or python2/python3 to
>> choose", and then it won't hurt to switch python to be python3.
>> Are there known distros in w
On Wed, Jan 7, 2015 at 2:48 PM, Guido van Rossum wrote:
> There's a proof of concept patch in http://bugs.python.org/issue22906, but
> it doesn't have the __future__ import and probably gets other details wrong.
>
> Reference:
> PEP 479 -- Change StopIteration handling inside generators
>
> --
> -
On Tue, Feb 24, 2015 at 2:44 AM, Guido van Rossum wrote:
> I think that's a bit too strong. This has been unquestionably valid, correct
> Python -- it was an intentional feature from the start. It may not have
> turned out great, but I think that before warning loudly about every
> instance of thi
On Tue, Feb 24, 2015 at 3:12 AM, Brett Cannon wrote:
>
>
> On Mon Feb 23 2015 at 10:55:23 AM Chris Angelico wrote:
>>
>> On Tue, Feb 24, 2015 at 2:44 AM, Guido van Rossum
>> wrote:
>> > I think that's a bit too strong. This has been unquestionably val
On Tue, Feb 24, 2015 at 7:40 PM, M.-A. Lemburg wrote:
> I think the easiest way would be to tweak the error message
> output to indicate the real problem.
>
> At the moment, you get:
>
open('c:\test.txt')
> Traceback (most recent call last):
> File "", line 1, in
> FileNotFoundError: [Errn
On Wed, Feb 25, 2015 at 6:54 AM, Greg Ewing wrote:
> Chris Angelico wrote:
>>
>> Then he changed the code over to use his
>> own file instead of the provided sample, and at the same time,
>> switched from using open() to using csv.reader(open()), and moved all
>&
On Wed, Feb 25, 2015 at 5:00 PM, Ben Finney wrote:
> There is a wider context here, too: semantics of the backslash escape
> https://en.wikipedia.org/wiki/Backslash#Usage> commonly include
> “backslash followed by a character not otherwise mentioned will produce
> that character, verbatim”.
>
> Pr
on a patch -- I'm sure
I'll have questions for Python-dev when I actually do that, but I'll get
started on my own and see how far I get.
-Chris
On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum wrote:
> I think it's time to accept PEP 485. I've re-read it once mo
On Fri, Feb 27, 2015 at 12:07 PM, Chris Barker
wrote:
> I'll edit the text as you suggest,
>
Done.
> and then work on a patch -- I'm sure I'll have questions for Python-dev
> when I actually do that, but I'll get started on my own and see how far I
> get.
&
t; (*) Adding it to the decimal module would require a discussion with
> Raymond Hettinger, but Decimal users can probably copy and paste the
> formula from the PEP.
>
>
yup -- but maybe worth putting in there while we're at it. though as
Decimal is arbitrary precision, maybe it's
*".
>
> +1
>
What do folks think? If we're going to do this, I'll write isclose() in
python. And I could do the work to split it out, too, I suppose.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206)
sing other reasons to do it.
Back to look at K&R ;-)
-Chris
> On Wed, Mar 4, 2015 at 12:23 PM, Brett Cannon wrote:
>
>>
>>
>> On Wed, Mar 4, 2015 at 3:14 PM Chris Barker
>> wrote:
>>
>>> On Tue, Mar 3, 2015 at 8:43 AM, Ethan Furman wrote:
>
On Sat, Mar 7, 2015 at 6:09 AM, Benjamin Peterson wrote:
> I think it would be preferable deprecate -O and -OO and replace them
> with flags like --no-docstrings or --no-asserts. Ideally, "optimization"
> levels shouldn't change program semantics.
Plenty of C compilers have optimization levels th
On Wed, Mar 11, 2015 at 4:27 AM, lou xiao wrote:
> I find a bug in str.lstrip, when i call str.lstrip, i get this result.
>
> tiny➜ ~ python
> Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
> [GCC 4.8.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
a='dev
On Sat, Mar 28, 2015 at 8:39 PM, Victor Stinner
wrote:
> Are you able to reproduce these issues? I'm unable to reproduce them
> on Fedora 21. Maybe they are more likely on Debian-like operating
> systems?
I just tried it on my Debian Wheezy AMD64, not running as root. (The
same computer the build
On Sat, Mar 28, 2015 at 9:10 PM, Chris Angelico wrote:
> On Sat, Mar 28, 2015 at 8:39 PM, Victor Stinner
> wrote:
>> Are you able to reproduce these issues? I'm unable to reproduce them
>> on Fedora 21. Maybe they are more likely on Debian-like operating
>> syste
On Sat, Mar 28, 2015 at 11:50 PM, Victor Stinner
wrote:
> Good, you are able to reproduce it. The next step is to identify the
> sequence of test to reproduce it. How do you run the test suite? Are you
> using -j1?
I just ran 'make test'. Early in the output are these lines:
./python ./Tools/sc
On Thu, Apr 9, 2015 at 8:32 AM, Alexander Belopolsky
wrote:
> A "named offset" is an abbreviation such as UTC, EST, MSK, MSD which (at any
> given time)
> corresponds to a fixed offset from UTC.
That assumes the abbreviations are unique. They're not. Just this
morning I had to explain to a new st
urse shoreten the names to "wall" and "utc" and "loc" if you
like, but I kind of like long, readable names..
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7
timezone?
Am I wrong, or is this a semantic question as to what "wall" time means?
Thanks for any clarification,
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voic
e as clear as possible
as to which function is being discussed when.
But anyway -- thanks all for hashing this out -- getting something
reasonable into datetime will be very nice.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-695
On Thu, Apr 16, 2015 at 1:00 AM, Lennart Regebro wrote:
> So because of this, perhaps we actually *should* change the internal
> representation to UTC, because that makes the issues I'm fighting with
> now so much simpler. (I'm currently trying to get arithmetic to do the
> right thing in all case
On Thu, Apr 16, 2015 at 1:43 AM, Lennart Regebro wrote:
> On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico wrote:
>> Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be
>> more logical to describe it as "adding six hours means adding six
>> hours
On Mon, Apr 20, 2015 at 11:30 AM, Harry Percival wrote:
> My first reaction to type hints was "yuck", and I'm sure I'm not the only
> one to think that. viz (from some pycon slides):
>
> def zipmap(f: Callable[[int, int], int], xx: List[int],
>yy: List[int]) -> List[Tuple[int,
On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich wrote:
> * It is not optional. Please stop saying that. The people promoting it would
> prefer that everyone use it. If it is approved it will be optional in the
> way that PEP8 is optional. If I'm reading your annotated code it is
> certainly /not/
On Tue, Apr 21, 2015 at 10:52 AM, Ben Finney wrote:
> Chris Angelico writes:
>
>> On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich wrote:
>> > * It is not optional. Please stop saying that. The people promoting
>> > it would prefer that everyone use it. If it is app
On Tue, Apr 21, 2015 at 6:58 PM, Cory Benfield wrote:
> On 21 April 2015 at 01:45, Chris Angelico wrote:
>> When you're writing a library, it can be a great help to provide type
>> annotations, because every application that uses your library can
>> benefit.
>
>
uot;.
Currently, the burden is a heavier one (type inference, rather than
reading it from a file) but borne by people best placed to handle it
(authors of IDEs, type checking software, etc).
Chris
___
Python-Dev mailing list
Python-Dev@python.
0 years time when I've had
to move to Javascript or because everyone
else has drifted away from Python as it had become ugly...
Chris
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsub
the
documentation specification and having a checker check that rather than
changing the syntax of the language...
Chris
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https
uot;.
Currently, the burden is a heavier one (type inference, rather than
reading it from a file) but borne by people best placed to handle it
(authors of IDEs, type checking software, etc).
Chris
___
Python-Dev mailing list
Python-Dev@python.
that I would be kicking myself in 5-10 years time when I've had
to move to Javascript or because everyone
else has drifted away from Python as it had become ugly...
Chris
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
On Tue, Apr 21, 2015 at 7:56 PM, Arnaud Delobelle wrote:
> If people constantly get told by their editor / IDE that they are calling
> function with the wrong argument types, what are they going to do? They may
> start adopting the same approach as in Java / C++ etc... where interfaces
> must be
On Wed, Apr 22, 2015 at 12:51 AM, Cory Benfield wrote:
> On 21 April 2015 at 15:31, Chris Angelico wrote:
>> Granted, there are some
>> vague areas - how many functions take a "file-like object", and are
>> they all the same? - but between MyPy types and the abst
te something from
:type input_object: (Nx3) numpy array or floats or somethign that can be
turned into one.
Is there any way for type hinting to help here???
- Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 v
ow here, is that this is all about "static typechecking".
It's not about run-time type checking.
It's not about type-base performance optimization.
It's not about any use of annotations other than types.
What is it about other than static typechecking?
-Chris
--
Christoph
ere -- stub files let pre-run-time
static type checking happen without cluttering up Python for the rest of us
-- so a nice compromise.
So I guess we'll see.
- Chris
On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich wrote:
> Twelve years ago a wise man said to me "I suggest that you
olve any others?
Do we want this to work around a quirk in Pythons string type?
NOTE: I know full well that adding a character type to Python is not worth
it.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
760
Somehow, I've always been uncomfortable with checking specifically for the
str type -- guess I want everything to be fully duck-typable.
But then I wouldn't be doing type hints, either, would I?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&
On Sun, Apr 26, 2015 at 2:01 AM, Ronan Lamy wrote:
>>> * PEP484 hints are too high-level. Replacing an 'int' object with a
>>> single machine word would be useful, but an 'int' annotation gives no
>>> guarantee that it's correct (because Python 3 ints can have arbitrary
>>> size and because subcla
On Thu, Apr 30, 2015 at 11:03 AM, Stephen J. Turnbull
wrote:
> Note that even if you have a UTF-8 input source, some users are likely
> to be surprised because IIRC Python doesn't canonicalize in its
> codecs; that is left for higher-level libraries. Linux UTF-8 is
> usually NFC normalized, while
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg wrote:
> By providing a way to intentionally switch off the new default,
> we do make people aware of the risks and that's good enough,
> while still maintaining the contract people rightly expect of
> patch level releases of Python.
Just as long as
On Wed, May 13, 2015 at 3:04 AM, Larry Hastings wrote:
> Workflow 1
> ==
>
> When I ship beta 1, we create the 3.5 branch. trunk become 3.6.
>
> When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically
> visible repo on bitbucket for 3.5.0, and we use bitbucket "pull reque
On Wed, May 13, 2015 at 8:15 AM, David Wilson wrote:
> SPF only covers the envelope sender, so it should be possible to set
> that to something that validates with SPF, keep the RFC822 From: header
> as it is, and maybe(?) include a separate Sender: header matching the
> envelope address.
As Came
On Mon, May 18, 2015 at 1:04 AM, Yury Selivanov wrote:
> Chris,
>
> Could you please add a link to the email where the PEP was accepted?
Sure. A Resolution: header is the right way to do this? Done.
ChrisA
___
Python-Dev mailing list
P
On Mon, Sep 11, 2017 at 7:29 AM, Koos Zevenhoven wrote:
> On Sun, Sep 10, 2017 at 8:21 PM, Barry Warsaw wrote:
>>
>> On Sep 9, 2017, at 15:12, Guido van Rossum wrote:
>> >
>> > I can't tell whether this was meant seriously, but I don't think it's
>> > worth it. People can easily write their own
On Mon, Sep 11, 2017 at 11:03 AM, Barry Warsaw wrote:
> On Sep 10, 2017, at 14:39, Chris Angelico wrote:
>>
>> As a language change, definitely not. But I like this idea for
>> PYTHONBREAKPOINT. You set it to the name of a function, or to "pass"
>> if you wa
On Thu, Sep 7, 2017 at 3:49 PM, Larry Hastings wrote:
> But I can cite at least one place in the standard library that would have
> been better if it'd been implemented as a module property:
>
os.stat_float_times().
>
I wish there were a property feature available almost very time I encounter
a
On Mon, Sep 11, 2017 at 10:20 AM, Victor Stinner
wrote:
> 2017-09-11 19:00 GMT+02:00 Chris Barker :
> > There are a heck of a lot in the os module:
> > ['get_blocking',
>
> This one is not a good example: it takes a parameter. You cannot
> convert it to a pr
This really isn't the place to ask this kind of question.
If you want to know how to do something with python, try python-users ,
stack overflow, etc.
If you have an idea about a new feature you think python could have, then
the python-ideas list is the place for that. But if you want anyone to t
On Wed, Sep 13, 2017 at 12:11 PM, Matthieu Bec wrote:
> Regarding your example, I think it gives the illusion to work because
> sleep() is GIL aware under the hood.
>
>
It'll work for anything -- it just may not buy you any performance.
I don't know off the top of my head if file I/O captures th
On Sun, Oct 8, 2017 at 7:02 PM, David Cournapeau wrote:
> It is certainly true that for a CLI tool that actually makes any network
> I/O, especially SSL, import times will quickly be negligible. It becomes
> tricky for complex tools, because of error management. For example, a common
> pattern I h
On Thu, Oct 12, 2017 at 3:20 AM, Steve Holden wrote:
> The reason I liked "row" as a name is because it resembles "vector" and
> hence is loosely assocaited with the concept of a tuple as well as being
> familiar to database users. In fact the answer to a relational query was, I
> believe, ori
ld not do with decorators? or it in a cleaner,
easier to write or understand way?
There-should-be-one--and-preferably-only-one--obvious-way-to-do-it-ly yours,
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 S
On Mon, Oct 23, 2017 at 2:06 AM, Wes Turner wrote:
> What about bus latency (and variance)?
I'm currently in Los Angeles. Bus latency is measured in minutes, and
may easily exceed sixty of them. :|
Seriously though: For applications requiring accurate representation
of relativistic effects, the
On Sun, Oct 22, 2017 at 1:42 PM, Wes Turner wrote:
> Aligning simulation data in context to other events may be enlightening:
> is there a good library for handing high precision time units in Python
> (and/or CFFI)?
>
Well, numpy's datetime64 can be set to use (almost) whatever unit you want:
On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan wrote:
> If one simply replaces the 'T' with a space and trims it after the '.',
> IIRC, it parses fine.
>
sure, but really, can anyone argue that it's not a good idea for datetime
ot be able to read the iso format it puts out???
-CHB
> -- H
>
> O
m: Alexander Belopolsky [mailto:alexander.belopol...@gmail.com]
> > Sent: Wednesday, October 25, 2017 4:33 PM
> > To: Alex Walters
> > Cc: Elvis Pranskevichus ; Python-Dev > d...@python.org>; Chris Barker
> > Subject: Re: [Python-Dev] iso8601 parsing
> >
> > On Wed, Oct 25,
On Wed, Oct 25, 2017 at 4:22 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> > times. The only difference is that instead of calling the type directly,
> > you call the appropriate classmethod.
> >
> > What am I missing?
>
> Nothing. The only annoyance is that the data processi
On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner wrote:
> ISO 8601 support offsets, but not time zones -- presumably the __str__
>> supports the full datetime tzinfo somehow. Which may be why .isoformat()
>> exists.
>>
>
> ISO8601 does support timezones.
> https://en.wikipedia.org/wiki/ISO_8601#Time_z
On Mon, Nov 6, 2017 at 9:36 PM, Stefan Krah wrote:
> On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote:
>> MicroPython hashmap implementation is effectively O(n) (average and
>> worst case) due to the algorithm parameters chosen (like the load factor
>> of 1). Of course, parameters c
ot;".join(data) == "".join(data2) == "abc", "key order failed"
>
> Getting from the "Works on CPython 3.6+ but is technically
> non-portable" state to a fully portable correct implementation that
> ensures a particular key order in the JSON
On Mon, Nov 6, 2017 at 11:23 AM, Paul G wrote:
> (Of course, given that CPython's implementation is order-preserving, a
> bunch of code is probably now being written that implicitly requires on
> this detail, but at least having syntax that makes that clear would give
> people the *option* to mak
On Wed, Nov 8, 2017 at 1:32 AM, Antoine Pitrou wrote:
> On Wed, 8 Nov 2017 00:01:04 +1000
> Nick Coghlan wrote:
>
>> On 7 November 2017 at 23:48, Stefan Krah wrote:
>> >
>> >
>> > This is just a reminder that the current dict is not an "OrderedDict":
>> >
>> from collections import OrderedD
On Tue, Nov 7, 2017 at 11:50 AM, Tim Peters wrote:
> Is it worth guaranteeing that will always "work" (as intended)? Not
> to me, but I do have code that relies on it now -
This is critically important -- no one looks at the language spec to figure
out how something works -- they try it, and i
On Tue, Nov 7, 2017 at 7:21 AM, David Mertz wrote:
> But like Raymond, I make most of my living TEACHING Python.
>
and I make least of my living TEACHING Python ( :-) ),and:
> I feel like the extra order guarantee would make teaching slightly harder.
>
I can't understand how this possibly mak
On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou wrote:
> On Sun, 12 Nov 2017 19:48:28 -0800
> Nathaniel Smith wrote:
>> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
>> > This change will lead to DeprecationWarning being displayed by default for:
>> >
>> > * code executed directly at the
On Thu, Nov 23, 2017 at 3:36 PM, Greg Ewing wrote:
> Paul Moore wrote:
>>
>> 3. List comprehensions are the same as list(the equivalent generator
>> expression).
>
>
> I don't think that's ever been quite true -- there have
> always been odd cases such as what happens if you
> raise StopIteration
On Wed, Nov 22, 2017 at 4:32 PM, Victor Stinner
wrote:
> Aha, contextlib.nullcontext() was just added, cool!
>
So is this equivalent to--
@contextmanager
def yielding(x):
yield x
I thought we were against adding one-line functions?
--Chris
>
> https://githu
On Fri, Nov 24, 2017 at 1:21 AM, Paul Moore wrote:
> On 23 November 2017 at 13:04, Ivan Levkivskyi wrote:
>> Let us forget for a moment about other problems and focus on this one: list
>> comprehension is currently not equivalent to a for-loop.
>> There are two options:
>> - Fix this, i.e. make c
101 - 200 of 1932 matches
Mail list logo
