On Sat, Aug 2, 2014 at 1:35 PM, David Wilson wrote:
> > Repeated list and str concatenation both have quadratic O(N**2)
> > performance, but people frequently build up strings with +
>
> join() isn't preferable in cases where it damages readability while
> simultaneously providing zero or negat
On Mon, Aug 4, 2014 at 11:10 AM, Steven D'Aprano
wrote:
> On Mon, Aug 04, 2014 at 09:25:12AM -0700, Chris Barker wrote:
>
> > Good point -- I was trying to make the point about .join() vs + for
> strings
> > in an intro python class last year, and made the mistake of ha
On Thu, Aug 7, 2014 at 4:01 PM, Ethan Furman wrote:
> I don't remember where, but I believe that cPython has an optimization
> built in for repeated string concatenation, which is probably why you
> aren't seeing big differences between the + and the sum().
>
Indeed -- clearly so.
A little test
On Mon, Aug 11, 2014 at 11:07 PM, Stephen J. Turnbull
wrote:
> I'm referring to removing the unnecessary information that there's a
> better way to do it, and simply raising an error (as in Python 3.2,
> say) which is all a RealProgrammer[tm] should ever need!
>
I can't imagine anyone is sugges
ouraging form core devs, so I guess that's it.
Thanks for the fun bike-shedding...
-Chris
> Chris Barker writes:
> > On Mon, Aug 11, 2014 at 11:07 PM, Stephen J. Turnbull <
> step...@xemacs.org>
> > wrote:
> >
> > > I'm referring to removing
On Sun, Aug 17, 2014 at 2:41 PM, Barry Warsaw wrote:
> I think the biggest API "problem" is that default iteration returns
> integers
> instead of bytes. That's a real pain.
>
what is really needed for this NOT to be a pain is a byte scalar.
numpy has a scalar type for every type it supports -
On Mon, Aug 18, 2014 at 1:06 PM, Terry Reedy wrote:
> The byte scalar is an int in range(256). Bytes is an array of such.
>
then why the complaint about iterating over bytes producing ints? Ye,s a
byte owuld be pretty much teh same as an int, but it would have
restrictions - useful ones.
numpy
>
> but disallowing them in higher level
>> > explicitly cross platform abstractions like pathlib.
>>
>
I think the trick here is that posix-using folks claim that filenames are
just bytes, and indeed they can be passed around with a char*, so they seem
to be.
but you can't possible do anything o
On Wed, Aug 20, 2014 at 9:52 PM, Cameron Simpson wrote:
> On 20Aug2014 16:04, Chris Barker - NOAA Federal
> wrote:
>
>>
> So really, people treat them as
>>>
>> "bytes-in-some-arbitrary-encoding-where-at-least the-slash-character-(and
>> maybe a c
On Fri, Aug 22, 2014 at 10:09 AM, Glenn Linderman
wrote:
> What encoding does have a text file (an HTML, to be precise) with
> text in utf-8, ads in cp1251 (ad blocks were included from different
> files) and comments in koi8-r?
>Well, I must admit the HTML was rather an exception, but ha
On Thu, Aug 21, 2014 at 7:42 PM, Oleg Broytman wrote:
> On Thu, Aug 21, 2014 at 05:30:14PM -0700, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
> > This brings up the other key problem. If file names are (almost)
> > arbitrary bytes, how do you write one
On Sun, Aug 31, 2014 at 3:00 PM, Nick Coghlan wrote:
>
> However, we still think we should start providing pip by default to Python
> 2.7 users as well, at least as part of the Windows and Mac OS X installers.
>
serious +1 here.
Just last night I was writing up notes for an intro to python class
On Tue, Sep 23, 2014 at 10:27 AM, Ned Deily wrote:
> Thanks for the feedback, Carol. Let us know via bugs.python.org of any
> issues you see. BTW, the new installer format will be coming to Python
> 2.7.9 as well.
>
Are the supported platforms going to be the same? i.e.:
10.3+ -- Intel32+PPC3
On Thu, Sep 25, 2014 at 9:00 AM, Donald Stufft wrote:
> 1) Just always default to —user and add a —system or similar flag, this
> is super easy to change but is a backwards incompatible change and
> would need to go through a deprecation window.
>
Maybe would have been the way to go to b
On Thu, Sep 25, 2014 at 5:38 PM, Donald Stufft wrote:
> 2) Switch to —user based on if the user has permission to write to the
>> site-packages or not.
>>
>
> ouch -- no. Why not a clear error message if pip can't write to
> site-packages -- something like:
>
> I fairly strongly believe that
OK, this seems weird to me:
For what it’s worth, I almost exclusively write 2/3 compatible code (and
> that’s
> with the “easy” subset of 2.6+ and either 3.2+ or 3.3+)
ouch.
> However the way it "used" to work
> is that the newest version, with all the new features, would quickly become
> the
On Sat, Jan 10, 2015 at 3:28 AM, Nick Coghlan wrote:
> For the time being, things like PyInstaller, PyRun, Portable Python,
> etc are going to offer a better solution than anything we provide in
> the standard installers.
>
See also Anaconda and Enthought Canopy. I think miniconda, for instance,
Thank you Guido.
It'll be nice to see this all come to something.
Thanks to all who contributed to the discussion -- despite this being a
pretty simple function, I learned a lot and far more fully appreciate the
nuance of all of this.
I'll edit the text as you suggest, and then work on a patch -
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.
&
not needed....
-Chris
> On Monday, March 2, 2015, Chris Barker wrote:
>
>> On Fri, Feb 27, 2015 at 12:07 PM, Chris Barker
>> wrote:
>>
>>> I'll edit the text as you suggest,
>>>
>>
>> Done.
>>
>>
>>> and then wo
On Tue, Mar 3, 2015 at 8:43 AM, Ethan Furman wrote:
> On 03/03/2015 01:17 AM, Victor Stinner wrote:
>
> > Maybe it's time to rename the math module to _math and create a
> > math.py module, like _decimal/decimal? math.py should end with "from
> > _math import *".
>
> +1
>
What do folks think?
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 Mon, Apr 13, 2015 at 10:45 AM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> Am I wrong, or is this a semantic question as to what "wall" time means?
>>
>
> You are right about what wall() means, but I should have been more
> explicit about knowns and unknowns in the wall(lo
Sorry to be brain dead here, but I'm a bit lost:
On Fri, Apr 10, 2015 at 4:32 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> For any given geographical location, loc, and a moment in time t expressed
> as UTC time, one can tell what time was shown on a "local clock-tower."
>
On Mon, Apr 13, 2015 at 12:14 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> utc_time = f( location, utc_time )
>>
>> These are two different problems, and one is much harder than the other!
>> (though both are ugly!)
>>
>
> You probably meant "utc_time = f( location, wall_tim
On Tue, Apr 21, 2015 at 2:33 AM, Cory Benfield wrote:
> It seems like the only place the type annotations will get used is in
> relatively trivial cases where the types are obvious anyway. I don't
> deny that *some* bugs will be caught, but I suspect they'll
> overwhelmingly be crass ones that wo
On Tue, Apr 21, 2015 at 11:58 AM, Paul Sokolovsky wrote:
> It does, and hope people won't be caught in "static typechecking"
> loop and consider other usages too.
>
I"m confused -- from the bit I've been skimming the discussion, over on
python-ideas, and now here, is that this is all about "stat
Thank you Jack.
Jack: "I hate code and I want as little of it as possible in our product"
I love that quote -- and I ALWAYS use it when I teach newbies Python. It's
kind of the point of Python -- you can get a lot done by writing very
little code.
I'm still confused about what all this type anno
> Oh wait, maybe it won't -- a string IS a sequence of strings. That's why
> this is an insidious bug in the first place.
On Tue, Apr 21, 2015 at 11:32 PM, Terry Reedy wrote:
> I was just thinking today that for this, typing needs a subtraction
> (difference) operation in addition to an additio
On Wed, Apr 22, 2015 at 5:45 PM, Guido van Rossum wrote:
> Given that even if Difference existed, and even if we had a predefined
> type alias for Difference[Iterable[str], str], you' still have to remember
> to mark up all those functions with that annotation. It almost sounds
> simpler to just
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 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
I think we've drifted into a new topic, but...
I was astonished to see them
> implemented using decorators, and I was not the only one.
...
> Python is at a weird point here. At about every new release of Python,
> a new idea shows up that could be easily solved using metaclasses, yet
> ever
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 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 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
al
>>
>
> ___
> 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
>
>
--
Chris
-CHB
> On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky <
> alexander.belopol...@gmail.com> wrote:
>>
>>
>>
>> On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker
>> wrote:
>>
>>>
>>> indeed what is the holdup? I don'
On Tue, Dec 5, 2017 at 1:18 PM, Guido van Rossum wrote:
>
>
> I am very worried about this long and rambling PEP,
>
FWIW, I read the PEP on the bus this morning on a phone, and while lng, I
didn't find it too rambling. And this topic has been very often discussed
in very long and rambling mailing
On Wed, Dec 6, 2017 at 3:07 PM, Paul Ganssle wrote:
> Here is the PR I've submitted:
>
> https://github.com/python/cpython/pull/4699
>
> The contract that I'm supporting (and, I think it can be argued, the only
> reasonable contract in the intial implementation) is the following:
>
> dtstr =
'a' has no default value
b: None = 0 # assign a default value for 'b'
If, in fact, that would be the way to do it.
-Chris
On Fri, Dec 15, 2017 at 3:22 AM, Eric V. Smith wrote:
> On 12/15/2017 5:56 AM, Steve Holden wrote:
>
>> On Mon, Dec 11, 2017
.
So having that justification in the PEP would be good.
-CHB
On Fri, Dec 15, 2017 at 12:07 PM, Chris Barker
wrote:
> Sorry about the email mangling -- I do a lot of my listserve work on the
> bus on an iPhone, with the built -in mail client -- and it REALLY sucks for
> doing intersper
On Fri, Dec 15, 2017 at 9:39 AM, Mariatta Wijaya
wrote:
> I agree it's useful info :)
>
> I went ahead and made a PR [1].
>
Thanks! I added a couple comments to that PR.
> Not sure about updating PEP 498 at this point..
>
A little clarification text would be nice. I made a PR for that:
https
Good Bad or Neutral, this discussion makes my point:
Using typing annotation as a necessary part of a standard library module is
injecting typing into "ordinary" python in a new way.
It is no longer going to appear to be completely optional, and only of
concern to those that choose to use it (and
Now that dicts are order-preserving, maybe we should change prettyprint:
In [7]: d = {'one':1, 'two':2, 'three':3}
In [8]: print(d)
{'one': 1, 'two': 2, 'three': 3}
order preserved.
In [9]: pprint.pprint(d)
{'one': 1, 'three': 3, 'two': 2}
order not preserved ( sorted, I presume? )
With arbit
I'm really surprised no one seems to get my point here.
TL;DR:
My point is that having type annotation syntax required for something in
the stdlib is a significant step toward "normalizing" type hinting in
Python. Whether that's a good idea or not is a judgement call, but it IS a
big step.
@Chri
On Mon, Dec 18, 2017 at 7:41 PM, Steven D'Aprano
wrote:
> > With arbitrary order, it made sense to sort, so as to always give the
> same
> > "pretty" representation. But now that order is "part of" the dict itself,
> > it seems prettyprint should present the preserved order of the dict.
>
> I dis
On Tue, Dec 19, 2017 at 8:14 AM, Barry Warsaw wrote:
> On Dec 18, 2017, at 22:37, Nathaniel Smith wrote:
>
> > Wait, what? Why would changing pprint (so that it accurately reflects
> > dict's new underlying semantics!) be a breaking change? Are you
> > suggesting it shouldn't be changed in 3.7?
On Mon, Dec 18, 2017 at 11:49 PM, Eric V. Smith wrote:
> I also don't think it's surprising that you can put misleading information
> (including non-types) in type annotations. All of the documentation and
> discussions are quite clear that type information is ignored at runtime.
>
Sure -- but t
On Tue, Dec 19, 2017 at 8:47 AM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> I don't see any reason not to document tips and tricks with f-strings,
> and this is a nice and useful example. But it looks like TOOWTDI to
> me. The syntax is documented (6.1.3.1 in the Library
On Wed, Dec 20, 2017 at 5:29 PM, Eric V. Smith wrote:
> There is definitely a passive bias towards using types with dataclasses in
> that the Eric (the author) doesn't appear to want an example without them
> in the pep/docs.
>
>>
>> I'm not sure what such an example would look like. Do you mean
On Thu, Dec 21, 2017 at 11:55 AM, Terry Reedy wrote:
I think the understanding problem with this feature arises from two
> factors: using annotations to define possibly un-initialized slots is
> non-obvious; a new use of annotations for something other than static
> typing is a bit of a reversal
On Thu, Dec 21, 2017 at 3:36 PM, Gregory P. Smith wrote:
> But we already have ... which does - so I'd suggest that for people who
> are averse to importing anything from typing and using the also quite
> readable Any. (ie: document this as the expected practice with both having
> the same mea
On Fri, Dec 22, 2017 at 8:49 AM, Brett Cannon wrote:
> I think it's worth reminding people that if they don't like the fact
>> dataclasses (ab)use type hints for their succinct syntax that you can
>> always use attrs instead to avoid type hints.
>>
>
sure -- but this doesn't really address the i
On Fri, Dec 22, 2017 at 10:10 AM, Stephan Hoyer wrote:
> On Thu, Dec 21, 2017 at 6:39 AM Ivan Levkivskyi
> wrote:
>
>>
> * ... (ellipsis): this class may or may not be used with static type
>> checkers, use the inferred type in the latter case
>>
>
> * "field docstring": this class should not
___
> 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
>
--
Christopher Barker, Ph.D.
On Sat, Dec 23, 2017 at 5:54 PM, Nick Coghlan wrote:
>
> I still wonder about the "fields *must* be annotated" constraint though. I
> can understand a constraint that the style be *consistent* (i.e. all fields
> as annotations, or all fields as field instances), since that's needed to
> determine
On Sat, Dec 30, 2017 at 7:27 AM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Just use the simple rule that a new
> __repr__ is generated unless provided in the dataclass.
>
are we only talking about __repr__ here ???
I interpretted Guido's proposal as being about all me
On Mon, Jan 1, 2018 at 7:50 PM, Ethan Smith wrote:
>
> Will you get the "right" __repr__ now if you derive a datacalss from a
>> dataclass? That would be a nice feature.
>>
>
>
> The __repr__ will be generated by the child dataclass unless the user
> overrides it. So I believe this is the "right"
Ned,
It looks like you're still building OS-X the same way as in the past:
Intel 32+64 bit, 10.6 compatibility
Is that right?
Might it be time for an update?
Do we still need to support 32 bit? From:
https://apple.stackexchange.com/questions/99640/how-old-are-macs-that-cannot-run-64-bit-appl
On Wed, Jan 31, 2018 at 3:13 AM, Joni Orponen
wrote:
> On Wed, Jan 31, 2018 at 12:43 AM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
>> And maybe we could even get rid of the "Framework" builds..
>>>
>>
>> Please do no
On Wed, Jan 31, 2018 at 4:20 AM, INADA Naoki wrote:
> > Against the official CPython 3.6 (probably .3 or .4) release I see:
> > 1 that is 2.01x faster (python-startup, 24.6ms down to 12.2ms)
> > 5 that are >=1.5x,<1.6x faster.
> > 13 that are >=1.4x,<1.5x faster.
> > 21 that are >=1.3x,<1.4x fast
>> Ned Deily is in charge of the Mac build (as well as current release
> manager). Within the last week, he revised the official builds (now two, I
> believe) for 3.7.0b1, due in a day or so. One will be a future oriented
> 64-bit build. The PR and What's New have more.
>
What's New doesn't men
On Fri, Feb 2, 2018 at 7:38 AM, Elvis Pranskevichus
wrote:
> On Friday, February 2, 2018 10:08:43 AM EST Eric V. Smith wrote:
> > However, I don't feel very strongly about this. As I've said, I expect
> > the use cases for hash=True to be very, very rare.
>
> Why do you think that the requirement
On Sun, Feb 4, 2018 at 7:54 PM, Nick Coghlan wrote:
> On 5 February 2018 at 08:31, Guido van Rossum wrote:
> > On Sun, Feb 4, 2018 at 11:59 AM, Chris Barker - NOAA Federal
> > wrote:
> >>
> >> I think the folks that are concerned about this issue are quite righ
On Sun, Feb 4, 2018 at 11:57 PM, Gregory P. Smith wrote:
> +1 using unsafe_hash as a name addresses my concern.
>
mine too -- anyone surprised by using this deserves what they get :-)
-CHB
On Sun, Feb 4, 2018, 9:50 PM Guido van Rossum wrote:
>
>> Looks like this is turning into a major flamew
On Mon, Feb 5, 2018 at 3:37 PM, Steven D'Aprano wrote:
> On Sun, Feb 04, 2018 at 09:18:25PM -0800, Guido van Rossum wrote:
>
> > The way I think of it generally is that immutability is a property of
> > types, while hashability is a property of values.
>
> That's a great way to look at it, thanks
Sorry -- too big a brain blip this morning.. my experiments were'n't
actually creating dataclasses properly.
Though it does show why the reliance on type hinting in troubling!!
IGNORE that message!
Sorry for the noise.
-CHB
On Mon, Feb 5, 2018 at 3:37 PM, Steven D'Aprano wrote:
> On Sun, Fe
I don't seem to be getting my own messages back to reply to, but:
yes, of course, dataclasses won't hash if a field is mutable:
In [*58*]: @dataclasses.dataclass(hash=*True*, frozen=*True*)
...: *class* *Hash*:
...: x: int = 5
...: l: list = dataclasses.field(default_fact
On Mon, Feb 5, 2018 at 5:17 PM, Steven D'Aprano wrote:
> I'm not happy about the concept of pandering to the least capable, most
> ignorant programmers by baking a miscomprehension into an important
> standard library API.
I don't think this is "baking a miscomprehension", but rather adhering t
On Tue, Feb 20, 2018 at 8:45 AM, Guido van Rossum wrote:
> TBH, I don't hate Nick's solution that assigns to __class__ in
> __post_init__. You can probably come up with a class decorator that hides
> construction of the frozen subclass. I do think that it should be used very
> sparingly, as the e
On Wed, Feb 21, 2018 at 11:55 AM, Elias Zamaria wrote:
> This is about some minor changes to the bytes, bytearray, and memoryview
> classes. Here is the PEP: https://www.python.org/dev/peps/pep-0467/
>
> I am waiting for this to be merged, or approved, or whatever is the next
> step. Someone on
On Wed, Feb 21, 2018 at 12:21 PM, Ethan Furman wrote:
> At this point the PEP itself has not been approved, and is undergoing
> changes. I don't see anything happening with it right now while 3.7 is
> going through it's final stages to release. Once 3.7.0 is published we can
> come back to this
On Wed, Feb 21, 2018 at 12:39 PM, Steve Holden wrote:
> I think the chances of a "byte" object are about as good as the chances of
> a character object
>
probably right.
> (though one can always implement such in C extensions, that wouldn't build
> them into the syntax).
>
I think you could s
On Fri, Feb 23, 2018 at 9:51 AM, Guido van Rossum wrote:
> As to the validity or legality of this code, it's both, and working as
> intended.
>
> A list comprehension of the form
>
> [STUFF for VAR1 in SEQ1 for VAR2 in SEQ2 for VAR3 in SEQ3]
>
> should be seen (informally) as
>
> for VAR1
On Fri, Feb 23, 2018 at 10:45 AM, Guido van Rossum wrote:
> There are useful things you can only do with comprehensions if the second
> for-loop can use the variable in the first for-loop. E.g.
>
> [(i, j) for i in range(10) for j in range(i)]
>
indeed -- and that is fairly common use-case in ne
On Fri, Mar 16, 2018 at 10:54 AM, Игорь Яковченко
wrote:
> I investigated problem and found that in ttk.py, Treeview.insert(...
> iid=None, ...) in method's body has a check:
> if iid:
> res = self.tk.call(self._w, "insert", parent, index,
> "-id", iid, *opts)
It seems .as_integer_ratio() has been resolved.
what about the original .is_integer() request? (Or did I miss that somehow?)
Anyway, it seems like __index__() should play a role here somehow... isn't
that how you ask an object for the integer version of itself?
Could float et al. add an __index_
On Wed, Mar 21, 2018 at 4:42 AM Steven D'Aprano wrote:
>
>
> > Could float et al. add an __index__ method that would return a ValueError
> > if the value was not an integer?
>
> That would allow us to write things like:
>
> "abcdefgh"[5.0]
>
> which is one of the things __index__ was invented to
>
>
> Does anybody know examples of the correct use of float.is_integer() in
> real programs? For now it looks just like a bug magnet. I suggest to
> deprecate it in 3.7 or 3.8 and remove in 3.9 or 3.10.
+1
It really doesn’t appear to be the right solution for any problem.
-CHB
--
Christopher
On Wed, Mar 21, 2018 at 11:43 PM, Tim Peters wrote:
> Note: this is a top-posted essay much more about floating-point
> philosophy than about details. Details follow from the philosophy,
> and if philosophies don't match the desired details will never match
> either.
>
but of course :-)
> Fr
On Wed, Mar 21, 2018 at 12:38 PM, Steven D'Aprano
wrote:
> In fact, Serhiy's suggestion is not correct when x is not a float:
>
This is a key point -- see some of Tim's posts -- like ot or not, you
probably need to know when you are working with a float and when you aren't
-- and what the implic
On Wed, Mar 21, 2018 at 4:12 PM, Guido van Rossum wrote:
> Thank you! As you may or may not have noticed in a different thread, we're
> going through a small existential crisis regarding the usefulness of
> is_integer() -- Serhiy believes it is not useful (and even an attractive
> nuisance) and s
might if we wanted to add a generic is_integer()
function somewhere.
In any case, I don’t recall it being mentioned in the conversation, so
thought I’d complete the record.
-CHB
On Wed, Mar 21, 2018 at 8:31 PM Guido van Rossum wrote:
> On Wed, Mar 21, 2018 at 6:48 PM, Chris Barker
>
On Thu, Apr 19, 2018 at 5:45 AM, Nick Coghlan wrote:
> * for the while loop use case, I think my discussion with Tim about
> tuple unpacking shows that the loop-and-a-half construct won't be
> going anywhere, so users would still end up needing to learn both
> forms (even for new code)
>
well, y
On Tue, Apr 24, 2018 at 2:21 AM, Victor Stinner wrote:
> Even if the C language allows assignments in if, I avoid them, because
> I regularly have to debug my own code in gdb ;-)
>
I personally haven't written a lot of C, so have no personal experience,
but if this is at all a common approach am
On Thu, Apr 26, 2018 at 1:33 PM, Tim Peters wrote:
> And that *is* a thing that you will have to explain to newbies when they
> encounter
> > it for the first time.
>
> Sure. That doesn't frighten me, though. It's easy to explain what it
> does - although it may be hard to explain when it's _d
Folks,
After a huge delay, I finally found the time to implement the PEP 485
isclose() function, in C. I tihnk it's time for some review. I appologise
for the fact that I have little experience with C, and haven't used the raw
C API for years, but it's a pretty simple function, and there's lots of
e handling the docsstrings
better and some more/better tests.
-Chris
On Sun, May 17, 2015 at 4:16 PM, Christian Heimes
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2015-05-18 01:02, Chris Barker wrote:
> > * Is there a better way to
Lisa,
As noted, not the right list.
But seeing this kind of stuff done in High Schools is GREAT!
So one suggestion:
If this is Windows, there are two versions of python for Windows: 32bit and
64bit -- if an installer for a third-party package is looking for one of
those, and the other is instal
Is it too late to get the isclose() code (PEP 485) into 3.5?
I posted the code here, and got a tiny bit of review, but have not yet
merged it into the source tree -- and don't know the process for getting it
committed to the official source.
So -- too late, or should I try to get that merge done
On Fri, May 22, 2015 at 2:33 PM, Larry Hastings wrote:
> On 05/22/2015 02:29 PM, Chris Barker wrote:
>
> Is it too late to get the isclose() code (PEP 485) into 3.5?
>
> ...
> Hopefully you can find a core dev familiar enough with the issues
> involved that they ca
1 - 100 of 366 matches
Mail list logo
