On Mon, Apr 28, 2014 at 1:56 PM, Mike Miller wrote:
> * watch Dave Beazley's PyCon 2014 talk for a good story involving one
>
>> of those manufacturer installed Pythons:
>> https://www.youtube.com/watch?v=RZ4Sn-Y7AP8
>>
>
> Thanks, I'm trying to get thru all the talk will watch that shortly. ;)
>
>
> [].sort() is None
> > True
> "ABC".lower() is None
> > False
> >
> > That's a deliberate design choice, and one that has been explained a
> > few times on the list when folks ask why "[].sort().reverse()" doesn't
> > work when "'ABC'.lower().replace('-', '_')" does.
> >
> > Would it b
Thanks all,
Now I need to try to sum this all up to present to my students. ;-)
-Chris
On Tue, May 20, 2014 at 4:56 PM, Terry Reedy wrote:
> On 5/20/2014 12:30 PM, Chris Barker wrote:
>
>> >>>> [].sort() is None
>> > True
>> >
On Thu, May 29, 2014 at 4:43 AM, Nick Coghlan wrote:
> For that last point, my interest is as much educational as it is in
> easing the transition from Python 2. The parentheses in "print('Hello
> world!')" mean introducing the idea of function calls early to explain
> how it works, while being a
>
>
> Why not just define Python 2.8 as Python 2.7 except with a newer compiler?
> I cannot see why that would be massive undertaking, if changing compiler
> for 2.7 is neccesary anyway.
>
A reminder that this was brought up a few months ago, as a proposal by the
stackless team, as they wanted to
On Sat, Jun 14, 2014 at 1:11 PM, Paul Sokolovsky wrote:
> > > 1. It hampers interactive mode - instead of short and easy to type
> > > execfile("file.py") one needs to use exec(open("file.py").read()).
>
> > If the amount of typing is the problem, that's easy to solve:
> >
> > # do this once
>
On Mon, Jun 16, 2014 at 3:39 PM, Nick Coghlan wrote:
> > FWIW, when I started using python (15?) years ago -- the first thing I
> looked for was a way to "just run a file", at the interactive prompt, like
> I had in MATLAB. I found and used execfile().
>
> Yes, if people are looking for a MATLAB
On Wed, Sep 7, 2016 at 10:37 AM, Guido van Rossum wrote:
> And apart from Python, few shell commands that work on
> Unix make much sense on Windows,
Does the (optional) addition of bash to Windows 10 have any impact on this?
It'll be something that Windows developers can't count on their users
> > - Standard integer types in and
>
> Yes, I will clarify we require the fixed-width types.
Does this mean that we might be able to have the built-in integer be based
on int64_t now? so Windows64 and *nix64 will be the same?
- CHB
--
Christopher Barker, Ph.D.
Oceanographer
Em
On Thu, Sep 8, 2016 at 9:17 AM, Benjamin Peterson
wrote:
> > Does this mean that we might be able to have the built-in integer be
> > based
> > on int64_t now? so Windows64 and *nix64 will be the same?
>
> The builtin integer type (in Python 3) is variable length.
>
indeed it is -- py2.7 also??
On Thu, Sep 8, 2016 at 9:39 AM, Random832 wrote:
> You're talking about changing Py_ssize_t, right?
>
wouldn't that be the pointer size?
Is there a "long" in there anywhere in the integer implementation?
My example is this:
on OS-X, py3.5:
import numpy as np
In [9]: arr = np.array([1,2,3])
On Thu, Sep 8, 2016 at 10:35 AM, Random832 wrote:
>
> It means that the so-called "bash" on windows 10 is actually a full
> Ubuntu system (running on, AIUI, a simulation of Linux kernel system
> calls), which will presumably also have its own python installation and
> use a UTF-8 locale, rather t
p 8, 2016 at 1:05 PM, Chris Barker
> wrote:
> > On Thu, Sep 8, 2016 at 10:35 AM, Random832
> wrote:
> >>
> >>
> >> It means that the so-called "bash" on windows 10 is actually a full
> >> Ubuntu system (running on, AIUI, a simulation of L
On Thu, Oct 20, 2016 at 11:48 PM, Nick Coghlan wrote:
> > len(get_builtin_methods())
> >>230
> >
> > So what? No one looks in all the methods of builtins at once.
>
> Yes, Python implementation developers do, which is why it's a useful
> part of defining the overall "size" of Python and h
Before the horse is totally dead... (maybe it already is), a couple
comments:
> In such cases, an extension module written in something like Cython, C
> or Rust would be a better fit,
well, yes, but:
> From that perspective, adding "[bytes/bytearray].frombuffer"
this would be used for the f
On Tue, Oct 25, 2016 at 12:25 AM, Nick Coghlan wrote:
> The suggestion came from folks working on asyncio performance
> improvements,
> I'm *absolutely* suggesting
> that they put some paid time and energy into a lower level buffer
> manipulation library between now and the Python 3.7 featur
Please don't get rid of unicode+literals -- I don't even think we should
depreciate it as a recommendation or discourage it.
Maybe a note or two added as to where issues may arise would be good.
I've found importing unicode_literals to be an excellent way to write py2/3
code. And I have never fou
On Mon, Jan 9, 2017 at 12:29 PM, Terry Reedy wrote:
> The tkinter doc still has
>
> ...to use Tkinter all you need is a simple import statement:
> import tkinter
> Or, more often:
> from tkinter import *
>
> Should this be changed?
>
yes, it should.
I would suggest suggesting something like
This is a list for python interpreter development, not new ideas -- that
list is python-ideas.
However, sorry to be blunt, but this post shows great ignorance of Python
-- please study up more in the future before posting suggestions on any
list.
Specifics:
1) this has nothing to do with the pri
There was a bunch of discussion about all this a while back, in which I
think these points were addressed:
However, in some cases the C locale is a normal environment for system
> services, cron scripts, distro package builds and whatnot.
>
Indeed it is. But:
if you run a Python (or any) program
Sorry to come late to the game, It wasn't immediately clear to me what the
implications were of the "enhancement or bugfix" distinction...
On Thu, May 4, 2017 at 9:46 PM, Nick Coghlan wrote:
> That improved casting mechanism and the implicit support in the low
> level APIs is the main benefit I
On Fri, May 5, 2017 at 2:34 PM, Terry Reedy wrote:
> So it would be really great if any updates to shutils (and other stdlib
>> packages) to support the new protocol be back-ported.
>>
>
> Not if they change the language.
we're not talking about language changes here -- we are talking about
upd
On Fri, May 5, 2017 at 9:30 PM, Nick Coghlan wrote:
> By contrast, 3.6 users can just unconditionally call os.fspath(), and
> know the result will work with all stdlib APIs, without allowing
> nonsense like attempting to use "str(str)" as a filesystem path.
>
> Doing that implicitly in various
On Mon, Jun 5, 2017 at 8:10 PM, Tim Peters wrote:
> [Tim]
> >> So at most 9 arenas ("highwater mark") were ever simultaneously
> allocated [by the
> >> time the REPL prompt appeared in a 64-bit 3.6.1]..
>
> > ... though not completely off-base.
>
> Yes, 9 is in the ballpark of 16.
>
>
> I think
As long as we are talking anecdotes:
If it could save a person’s life, could you find a way to save ten seconds
off the boot time? If there were five million people using the Mac, and it
took ten seconds extra to turn it on every day, that added up to three
hundred million or so hours per year peo
On Thu, Aug 31, 2017 at 5:12 PM, Antoine Pitrou wrote:
> I'm skeptical there are some programs out there that are limited by the
> speed of PyLong inplace additions.
>
indeed, but that could be said about any number of operations.
My question is -- how can the interpreter know if it can alter w
On Fri, Sep 1, 2017 at 6:16 PM, Joe Jevnik via Python-Dev <
python-dev@python.org> wrote:
> The string concat optimization happens in the interpreter dispatch for
> INPLACE_ADD
>
In that case, isn't there a new string being build, all in one line of
python? that is, the string the optimization is
Martin v. Löwis v.loewis.de> writes:
> Can you please give examples for real-world applications of this
> interface, preferably examples involving multiple
> independently-developed libraries?
OK -- here's one I haven't seen in this thread yet:
wxPython has a lot code to translate between vario
Martin v. Löwis wrote:
No. Normally, packages should aim for backwards compatibility, so that
applications would only want to specify a minimum version, such as
import xml
assert xml.version_info > (0,8,2)
Well, yes, but life is not always so simple, and while, as a rule,
version 2.3 should be bac
On 3/17/06, Thomas Heller python.net> wrote:
> Accessing Python arrays (Numeric arrays, Numeric array, or Numpy
> array) as ctypes arrays, and vice versa, without copying any memory,
> would be a good thing.
This does bring up a point. I was thinking that a really bare-bones
nd-array type wou
On Jun 26, 2014, at 4:38 PM, Tim Delaney
wrote:
On 27 June 2014 09:28, MRAB wrote:
>
> -1 for windows_wildcard (it would be an attractive nuisance to write
windows-only code)
Could you emulate it on other platforms?
+1 on the rest of it.
-Chris
__
> I'm very sympathetic to Steven's explanation that "we
> wouldn't be having this discussion if we used a different operator for
> string concatenation".
Sure -- but just imagine the conversations we could be having instead
: what does bit wise and of a string mean? A bytes object? I cod see
it as
Sorry for the bike shedding here, but:
The quadratic behaviour of repeated str summation is a subtle, silent error.
OK, fair enough. I suppose it would be hard and ugly to catch those
instances and raise an exception pointing users to "".join.
*is* controversial that CPython silently optimises s
> Does Unix even support UTF-16 as an encoding? I suppose, these days, it
> probably does, for reading contents of files created on Windows, etc.
I don't think Unix supports any encodings at all for the _contents_ of
files -- that's up to applications. Of course the command line text
processing t
Just want to make sure you're aware of the new mobile-sig:
https://mail.python.org/mailman/listinfo/mobile-sig
No need to do this on your own.
-Chris
> On Jan 27, 2015, at 4:21 PM, Cyd Haselton wrote:
>
>> On Tue, Jan 27, 2015 at 2:45 PM, Glenn Linderman
>> wrote:
>> On 1/27/2015 8:04 AM, Cy
> On Sep 12, 2017, at 9:01 AM, Chris Barker - NOAA Federal
> wrote:
> This really does match well with the record concept in databases, and most
> people are familiar with that. Though it will. E a touch confusing until (if
> ever) most of the database and cab traders, etc s
- record
+1
This really does match well with the record concept in databases, and most
people are familiar with that. Though it will. E a touch confusing until
(if ever) most of the database and cab traders, etc start using them.
It also matches pretty well with numpy "record arrays":
https://
This seems like overkill to me. By the same logic, we should add a
"delay garbage collection" mode, that allows people to test that their
code doesn't make unwarranted assumptions that a reference-counting
garbage collector is in use.
Actually, there is a LOT of code out there that expects ref
ccept both with and without the T.
Thanks for working on this.
-Chris
On 12/07/2017 08:12 PM, Chris Barker 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 co
I’m a bit confused:
File names and the like are one thing, and the CONTENTS of files is quite
another.
I get that there is theoretically a “default” encoding for the contents of
text files, but that is SO likely to be wrong as to be ignorable.
open() already defaults to utf-8. Which is a fine de
I made the following two changes to the PEP 540:
* open() error handler remains "strict"
* remove the "Strict UTF8 mode" which doesn't make much sense anymore
+1 — ignore my previous note.
-CHB
I wrote the Strict UTF-8 mode when open() used surrogateescape error
handler in the UTF-8 mode. I d
-07 17:57, Chris Barker - NOAA Federal wrote:
___
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
.
I see a couple of options:
1a: Use a default type annotation, if one is not is supplied. typing.Any
would presumably make the most sense.
1b: Use None if not type is supplied.
2: Rework the code to not require annotations at all.
I think I'd prefer 1a, since it's easy.
2) would be great :-)
That's covered under "format specifiers" I think.
The PEP mentions this:
https://www.python.org/dev/peps/pep-0498/#format-specifiers
I can see how a newbie might not realize that that means that f-strings use
the same formatting language as the .format() method, and or where to find
documentation
And maybe we could even get rid of the "Framework" builds..
>
Please do not. These make life easier for doing things the Apple way for
signed sandboxed applications.
Thanks — good to hear there is a good reason for them. I’ve always thought
that Frameworks were designed with other use-casss,
> It would be nice to do more things the Apple way, including porting to modern
> runtime feature availability check cascades of the Cocoa APIs and using the
> Apple provided system Frameworks. This seems like a rather major workload and
> should be targeting 3.8.
Yeah — too much to do for 3.7
>> IMO, the danger of
>> "@dataclass(hash=True)" far overweighs whatever convenience it might
>> provide.
Is there any reason specifying has=True could set frozen=True unless
the user specifically sets frozen=False?
Or is that already the case?
I think the folks that are concerned about this iss
If I have this right, on the discussion about frozen and hash, a use
case was brought up for taking a few steps to create an instance (and
thus wanting it not frozen) and then wanting it hashable.
Which pointed to the idea of a “ freeze this from now on” method.
This seems another use case — mayb
would also be a property
of values.
But it would require a flag, and a bunch of logic overhead, which could get
pretty ugly so maybe not worth it.
-CHB
On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> If I have this right, on the discuss
> Is it similar enough to
>
>def f(x=[0]):
No, not at all — it’s a very different use case.
When I first saw this on the original thread, I needed to stare at it
a good while, and then whip up some code to experiment with it to know
what it did.
And not because I don’t know what a single ele
Is bringing cmd2 into the standard library an option to be considered?
That water get included batteries and a more featurefull and supported lib.
It seems (on python-ideas) that people are often told, when they have
a suggestion for the stdlib, that they put it on pypi and see if it
gains usage,
> On Apr 19, 2018, at 4:27 PM, Christoph Groth wrote:
> def sync_runner(learner, f, static_hint):
>while True:
>points = learner.get(static_hint)
>if not points:
>break
>learner.feed(f(points))
>
>
>
> With assignment expressions the body of the above fun
> Personally, I even slightly prefer
>
> a := 3
>
> to the commonplace
>
> a = 3
> because it visually expresses the asymmetry of the operation.
Careful here! That’s a fine argument for using := in a new language,
but people using := when they don’t need an expression because they
like the symbol
> I'd like to backport those new project files to 2.7,
Would this change anything about how extensions are built?
There is now the "ms compiler for 2.7" would that work? Or only in
concert with VS2010 express?
-CHB
> and Intel is
> willing to fund that work as part of making Python ICC compilab
> I'm confident we're
> going to want a "support prebuilt wheels only" installation option
> downstream in the Linux distro world -
Interesting-- so move to a Python specific binary distribution option
-- rather than using rm or deb packages?
Doesn't lead to a dependency heck? I.e no way to expre
>Please don't add extra pain for purity and
>make sure that ensurepip installs "pip" and
>not "slow pip until you install wheel in the venv".
This is a really good point -- other than purity, what is the downside?
Arguably, the only reason setuptools, pip, and wheel are not in the
standard libra
> there's been enough debate that I suspect we need a
>> PEP.
>>
> I think we might just need another round of discussion here.
Please no :-)
Looking back at the previous discussion, it looked like it's all been
said, and there was almost unanimous approval (with some key mild
disapproval) for th
As I understand it, the MS VS2010 compiler is required (or at least
best practice) for compiling Python extensions for the python.org
Windows builds of py 3.4 and ?[1]
However, MS now makes it very hard (impossible?) to download VS2010
Express ( or Community, or whatever the free as in beer versio
> This is the main motivation for moving to VS 2015 for Python 3.5.
Yes,I've followed that work to the degree I understand it, and it
looks like a great move. Thanks so much for your (continuing) efforts
with this.
> put a bit of
>>
>> pressure on MS to make it available, as they have for VS2008
ssion for.
But it still may be the best bet. I'll give it a try when I have a chance.
And this should be in the "official" docs...
-CHB
On Sat, Sep 26, 2015 at 12:24 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> As I understand it, the MS VS2010 c
Sent from my iPhone
> On Sep 28, 2015, at 2:18 PM, Barry Warsaw wrote:
>
>> On Sep 28, 2015, at 08:22 AM, Guido van Rossum wrote:
>>
>> I saw that you had a need for an asyncio tutorial. I wonder if the "500
>> lines" chapter on asyncio would help? I didn't write it; I only write the
>> asyncio i
> I'm not sure why INADA Naoki's answer above wasn't sufficient for you?
It may be -- I've still have to test. Neither Windows nor py3 are my
primary production versions.
But the last time I tried the SDK approach was for py2.7 on Win64, and
it was both a pain, and impossible to set up to "just w
> On Sep 29, 2015, at 9:20 AM, Steve Dower wrote:
>
>> On 29Sep2015 0820, Chris Barker wrote:
>> OK -- I'm going to get off my soap box now -- time to actually suggest
>> doc patches
>
> Just bear in mind that you're suggesting patches for Python 3.3 a
TL;DR -- yes, documenting this in packaging.python.org would be great!
> Part of the problem here is that people put up postings saying "do
> this" having checked that it works for them, and then others say "but
> it doesn't work", without giving any information as to why or
> providing any means
I merely worry about what happens if people
> start relying upon the fact that a float annotation 'will handle all
> the numbers I care about' to the forgotten Decimal users such as
> myself.
Well, that's what you get in exchange for "type safety".
Which is exactly why I'm concerned about widesp
And these days
> anybody who is using Decimal for Money (which ought to be everybody,
I'm not so sure about that -- using base-10 is nice, but it doesn't
automatically buy you the appropriate rounding rules, etc that you
need to "proper" accounting.
And, as MA pointed out, in much "finance" work,
>> Well, that's what you get in exchange for "type safety".
>
> AIUI, the point of type annotations is that some use cases benefit *a
> lot* from machine-parsable type information, not that type annotation
> is a universally good idea in itself. It's not type *safety* that's
> the aim here. It's
> Yes, but what I expect the type annotations to be used for, especially
> in the SciPy world, is to make things easier for Numba to generate fast
> code.
Well, probably not.
There are two reasons to have type declarations: performance and type safety.
But the current type annotations are design
>> and there are a LOT of next-to worthless docstrings in the stdlib -- it
>> would be nice to clean them all up.
>>
>> Is there any reason not to, other than someone having to do the work?
And yes, I'd be willing to submit a patch.
> Is this just a matter of _datetimemodule.c (and various other
All I can say is "ouch". Hard to call it a regression to no longer
allow this mess...
CHB
> On Feb 8, 2016, at 4:37 PM, eryk sun wrote:
>
>> On Mon, Feb 8, 2016 at 2:41 PM, Chris Barker wrote:
>> Just to clarify -- what does it currently do for bytes? IIUC, Window
>> Ah, good point. I think that kills __path__ then as an option.
Darn. I really preferred that. Oh well.
> __fspath__
+0.1
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.
Which also means that I don't think we need a b
>> Personally, the main issue I have with remembering pathlib method
>> names, is the inconsistency with the existing modules.
Was this *really* not brought up when this was introduced? Oh well.
We could add aliases, but I think it's not such a big deal. I'm
convinced that the largest barrier to
> On Apr 8, 2016, at 3:00 PM, Eric Snow wrote:
>
>> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
>> I personally still like __ospath__ as well.
>
> Same here. The strings are essentially an OS-dependent serialization,
> rather than related to a particular file system.
Huh? I though the
> with the
> rationale being the one someone mentioned regarding ease-of-use in
> os.path.
>
> Consider os.path.join:
Why in the world do the os.path functions need to work with Path
objects? ( and other conforming objects)
Thus all started with the goal of using Path objects in the stdlib,
but
> On Apr 13, 2016, at 8:31 PM, Nick Coghlan wrote:
>
>>> class Special(bytes):
>>> def __fspath__(self):
>>> return 'str-val'
>>> obj = Special('bytes-val', 'utf8')
>>> path_obj = fspath(obj, allow_bytes=True)
>>>
>>> With #2, path_obj == 'bytes-val'. With #3, path_obj == 'str-
>> , which aren't in any wide spread use yet and
> probably won't be for quite a few years ahead.
Anything added to the stdlib now will be in py3.6+, yes?
Which won't be in widespread use for quite a few years yet, either.
So if ( and that's a big if) it's possible to anticipate what will be
in
On Nov 20, 2013, at 4:53 PM, Antoine Pitrou wrote:
>
> When pathlib-in-the-stdlib stabilizes, I plan to release a pathlib 1.0
> on PyPI that will integrate the PEP's API.
Great, thanks!
Chris
> In the meantime, if you don't mind installing from VCS, you clone the
> Mercurial repo (https://bi
with older releases (I admit I don't understand the ABI compatibility on
OSX).
Well, with OS-X, it's not exactly the C lic in the same way, but there are
different SDKs for different OS versions, and you can add to that PPC vs
Intel processors and 32 vs 64 bit.
So we have for years had two build
One added note:
>> if greeting == True:
>> if greeting is True:
>
> This one is based on the preference for identity checks when singletons are
> involved, rather than equality tests. Being composed of English words, the
> latter is also more readable. It's the same reason why you would do ident
On Apr 25, 2014, at 11:47 AM, Terry Reedy wrote:
>So I wonder whether the thought-to-be-buggy behavior is
>actually buggy with respect to *all* the supported styles or just some of them.
I can't how being able to write a file that isn't read back with the
same meaning could be anything but a bug
>>
>>
>> Method proliferation on builtins is a Big Deal(TM)
>
> I wanted to quantify this concept, so here's a quick metric that helps
> convey how every time we add a new builtin method we're immediately
> making Python harder to comprehend:
>
def get_builtin_types():
>... import buil
> The proposal is that it should be documented as being part of the
> language spec starting in 3.4 (or whatever).
Is the performance characteristics of any object part of the language spec?
I.e if someone wrote an implementation with an O(n) insert dict, it
would suck, but wouldn't it still be P
> This is what happens with numpy arrays:
>
> >>> bytes(numpy.array([2], 'i1'))
> b'\x00\x00'
>
> >>> bytes(numpy.array([2, 2], 'i1'))
> b'\x02\x02'
>
> For better or worse, single-element numpy arrays have a working __index__
> methods
Ouch -- that probably is for the worse..
There are Numpy
> This list is for development of furture releases. Questions about using
> current releases should go to python-list, Stackoverflow, or other help
> forums.
The python-Mac SIG would be a good one for this.
CHB
>
> --
> Terry Jan Reedy
>
>
> ___
> P
> Anyway, I think researching import tree of popular library is good
> startline
> about optimizing startup time.
>
I agree -- in this case, you've identified that asyncio is expensive --
good to know.
In the jinja2 case, does it always need asyncio?
Pep8 as side, I think it often makes sense fo
On Wed, May 2, 2018 at 8:21 PM, Terry Reedy wrote:
> On 5/2/2018 4:38 PM, Ivan Pozdeev via Python-Dev wrote:
>
>> The bottom line is: Tkinter is currently broken
>>
>
> This is way over-stated. Many modules have bugs, somethings in features
> more central to their main purpose.
I'll suggest a
On Fri, May 11, 2018 at 11:05 AM, Ryan Gonzalez wrote:
> https://refi64.com/uprocd/
very cool -- but *nix only, of course :-(
But it seems that there is a demand for this sort of thing, and a few major
projects are rolling their own. So maybe it makes sense to put something
into the standard
On Mon, May 14, 2018 at 12:33 PM, INADA Naoki
wrote:
> It will broke hash randomization.
>
> See also: https://www.cvedetails.com/cve/CVE-2017-11499/
I'm not enough of a security expert to know how much that matters in this
case, but I suppose one could do a bit of post-proccessing on the image
On Sat, May 12, 2018 at 8:14 AM, Skip Montanaro
wrote:
> > I have found 2to3 conversion to be remarkably easy and painless.
>
> > And the whole Unicode thing is much easier.
>
Another point here:
between 3.0 and 3.6 (.5?) -- py3 grew a lot of minor features that made it
easier to write py2/py3
Over on python-ideas, someone is/was proposing literals for timedeltas.
I don't expect that will come to anything, but it did make me take a look
at the docstring for datetime.timedelta. I use iPython's ? a lot for a
quick overview of how to use a class/function.
This is what I get:
In [8]: time
t; Clinic and then run "make clinic" to regenerate the generated files.
>
good idea.
Now to find some time to actually work on this...
-CHB
> Victor
>
> 2018-06-04 23:45 GMT+02:00 Chris Barker via Python-Dev <
> python-dev@python.org>:
> > Over on pytho
OK,
looking a bit deeper:
In [69]: timedelta.__new__.__doc__
Out[69]: 'Create and return a new object. See help(type) for accurate
signature.'
In [70]: timedelta.__init__.__doc__
Out[70]: 'Initialize self. See help(type(self)) for accurate signature.'
In [71]: timedelta.__doc__
Out[71]: 'Diff
elf,/, *args,
>> **kwargs), and if it is, it is useless we can attempt to get the signature
>> from __new__ and show that instead. We do similar things for docstrings,
>> if __init__ have no docstring we look at the class level docstring.
>> --
>> M
>>
>>
>>
Excuse my ignorance (or maybe it's a vocabulary thing), but I'm trying to
understand the problem here.
But if I have this right:
I've been using asyncio a lot lately and have encountered this problem
> several times. Imagine you want to do a lot of queries against a database,
> spawning 1 tas
On Fri, Jun 22, 2018 at 10:09 AM, Michael Selik wrote:
> I forgot to add that I don't anticipate changing my lesson plans if this
> proposal is accepted. There's already not enough time to teach everything
> I'd like. Including a new assignment operator would distract from the
> learning objectiv
On Fri, Jun 22, 2018 at 7:23 PM, Steven D'Aprano
wrote:
> > But once it becomes a more common idiom, students will see it in the wild
> > pretty early in their path to learning python. So we'll need to start
> > introducing it earlier than later.
>
> Students see many features early in their path
On Wed, Jun 27, 2018 at 12:01 PM, Eric V. Smith wrote:
> >>> def test():
> >>>spam = 1
> >>>ham = 2
> >>>vars = [key1+key2 for key1 in locals() for key2 in locals()]
> >>>return vars
> >>>
> >>> Wanna guess what that's gonna return?
>
Guessing aside, messing around with locals()
On Thu, Jun 28, 2018 at 9:28 AM, Tim Peters wrote:
> >>> g = (x:=i for i in range(3))
> Common or not, I have no idea why anyone would write a genexp like the one
> you gave, except to contrive an example of silly behavior exhibited by
> silly code ;-)
>
yes, it was a contrived example, but the
On Sun, Jul 1, 2018 at 8:35 AM, Michael Selik wrote:
> As Mark and Chris said (quoting Mark below), this is just one straw in the
> struggle against piling too many things on the haystack. Unlike some
> changes to the language, this change of such general use that it won't be
> an optional topic.
On Sun, Jul 1, 2018 at 5:25 PM, Steven D'Aprano wrote:
>
> > an optional topic. Once widely used, it ain't optional.
>
> Without knowing the details of your course, and who they are aimed at,
> we cannot possibly judge this comment. Decorators are widely used, but
> surely you don't teach them in
201 - 300 of 366 matches
Mail list logo
