Op ma 17 sep. 2018 om 16:40 schreef Wes Turner :
> I think it's meant to be ironic?
>
> Why would that be the first sentence of a poem about software and the
> Python newsgroup/mailing list community?
>
> A certain percentage of people might be offended by changing the first
> line (the frame of)
Op zo 16 sep. 2018 om 05:40 schreef Franklin? Lee <
leewangzhong+pyt...@gmail.com>:
> I am very disappointed with the responses to this thread. We have
> mockery, dismissiveness, and even insinuations about OP's
> psychological health. Whether or not OP is a troll, and whether or not
> OP's idea h
Yeah, sounds about as sensible as the recent "ban ugly" campaign.
+1.
Op zo 16 sep. 2018 om 15:49 schreef Wes Turner :
> Anyways, speaking of dragons, here are some ideas for new logos:
>
> "Strong Bad Email #58: Dragon"
> https://youtu.be/90X5NJleYJQ
>
> https://en.wikipedia.org/wiki/Monty_Pytho
Op vr 14 sep. 2018 om 08:07 schreef Anders Hovmöller :
>
> > I'd like to propose an extension for the warnings module
> > to address this problem.
>
> I like all of that. The only issue I have with it is that the warnings
> module is designed to namespace depredations so you can turn them on per
>
My mom is the only one who ever called me any shade of beautiful. I think
we all know what that means.
However, if merely the word ugly being on a page can be "harmful", what you
really need is professional help, not a change to Python. Because there's
obviously been some things in your past you n
Op do 13 sep. 2018 om 14:22 schreef Chris Angelico :
> On Thu, Sep 13, 2018 at 10:16 PM, João Santos wrote:
> > One important difference between master/slave and beautiful/ugly is that
> the
> > first pair are concrete concepts that typically applies to people, and
> the
> > second are abstract c
> I'm pleasantly surprised by the general response here. I was taking it
> seriously because, well, that's how far it's going everywhere.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of C
-1. The concept of ugly code is everywhere on the internet. Everyone on
this planet has either written ugly code or no code at all. Some have also
written beautiful code.
People aren't code, and code isn't people. I can't see this becoming a
problem until we have an AI that can feel insulted becau
Op di 11 sep. 2018 om 06:48 schreef Steve Barnes :
>
>
> On 10/09/2018 22:00, Ethan Furman wrote:
> > On 09/10/2018 12:52 PM, Chris Barker via Python-ideas wrote:
> >
> >> I've spent this whole thread thinking: "who in the world is writing
> >> code with a lot of spam=spam arguments? If you are tr
Op vr 7 sep. 2018 om 04:49 schreef Anders Hovmöller :
>
> Maybe something like this would be better:
>>
>> f(=a, =b, =c)
>>
>
> Haha. Look at my PEP, it's under "rejected alternative syntax", because of
> the super angry replies I got on this very mailing list when I suggested
> this syntax a
This feels really useful to me to make some quick changes to a database -
perhaps a database layer could return an class of type Recordclass, and
then you just simply mutate it and shove it back into the database.
Pseudocode:
record = database.execute("SELECT * FROM mytable WHERE primary_key = 15"
If we wanted to be mathematically correct, taking a 4th root should give
you 4 answers. You could return a tuple of (4, -4, 4j, -4j) for a 4th root
of 256. It actually makes power to a Fraction(2, 4) unequal with a
Fraction(1, 2) calculating this way. (which, from what I can tell, is
exactly your p
Op wo 29 aug. 2018 om 03:59 schreef Steven D'Aprano :
> On Tue, Aug 28, 2018 at 07:46:02AM +0200, Marko Ristin-Kaufmann wrote:
> > Hi,
> > To clarify the benefits of the contracts, let me give you an example from
> > our code base:
> >
> > @icontract.pre(lambda x: x >= 0)
> > @icontract.pre(lambda
Op ma 27 aug. 2018 om 23:18 schreef James Lu :
> > As Matthew points out, you could use numpy.array. Or code your own
> > class, by providing __add__ and __iadd__ methods.
> >
> > >>> import numpy
> > >>> a = numpy.array([1, 2])
> > >>> b = numpy.array([3, 4])
> > >>> a + b
> > array([4, 6])
> > >
Didn't see the Qt version of the adding together with GUI yet, so here I
have a minimalist version:
import sys
from PyQt5.QtWidgets import QWidget, QSpinBox, QLabel, QApplication,
QHBoxLayout
app = QApplication(sys.argv)
w = QWidget()
w.setLayout(QHBoxLayout())
spinOne = QSpinBox(w)
spinTwo = QS
Total noob speaking here, but
Those contracts are mostly important during development right ? Slowdown
isn't that much of an issue during development. So you could make a debug
mode that enforces the contracts, and a production mode that code users can
use during production to stop the slowdow
I think it would have been better to use def from the start instead of
lambda. The only thing JS does right is using the same "function" keyword
for both of these.
However, changing it now doesn't seem that important to me.
(And I've used lambda's as default argument - I was moving data from one
I would consider conciseness and accuracy most important. Using jargon but
linking to accurate explanations would, in my not exactly humble opinion,
be the best way to go about it.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.
I'm perhaps the newest and most ignorant subscriber here - I daresay
everyone here has superior python knowledge to me, and all my other
computing knowledge is inferior to what I can do with python. (and so far,
I've had no influence at all on python)
However, this mailing list, generally, does no
I actually really like the method-on-function-object syntax. +1, for
what it's worth from someone like me.
2018-08-10 0:46 GMT+02:00 Neil Girdhar :
> I prefer partial since many programmers studied computer science, and also
> it makes the concepts easier to google.
>
> Anyway, I don't actually wa
I don't think this is a major problem. In this case, the file will be
closed when the generator is garbage collected. So you'd also have to
leak the generator to actually get this problem. And if leaking
generators won't harm your application, neither will leaking the
occasional file handle.
Also,
I think the extra 9 characters of "_probable" are worth the extra accuracy.
Dont teach people to lie in their function names. It's a bad example.
and if you really want to lie, just
from imath import is_probably_prime as is_prime
2018-07-13 14:44 GMT+02:00 Jeroen Demeyer :
> On 2018-07-13 14:11,
2018-07-13 11:13 GMT+02:00 Jeroen Demeyer :
> On 2018-07-13 10:43, Jacco van Dorp wrote:
>>
>> If there's going to be failure possible primality tests, there should
>> also exist certain ones. No matter how slow it can be to do it.
>
>
> A certain primality te
If there's going to be failure possible primality tests, there should
also exist certain ones. No matter how slow it can be to do it.
Python if often a language for beginners. I think it'd be confusing to
a lot of people that there's going to be tests that show "This one is
probably prime", instea
I've had it to, bounces when attempting to reply or reply all, and it
tried to send to some google groups version.
2018-06-28 19:31 GMT+02:00 Eric Fahlgren :
> I've been getting those, too, but from the wxPython-dev group. I concur
> that they look like googlegroups bounces (although I can't conf
> Greg
> Or perhaps this could be made to work somehow:
>
> class Color(Enum(int)):
> RED = 1
> GREEN = 2
> BLUE = 3
> i_get_left_alone = 4.2
Enum already is callable - it creates Enum subclasses.
e.g.
Color = Enum("Color", ("RED", "GREEN", "BLUE"))
(or somet
Have you tried just instantiating a Counter() instead ? All missing
keys are considerd to be 0 in a fresh counter. So for example:
>>> c = Counter()
>>> c["a"] += 1
>>> c
Counter({'a': 1})
>>> c["b"]
0
works exactly this way. Which means there's no difference between what
you're suggesting Counte
2018-06-27 9:36 GMT+02:00 Michael Selik :
>
>
> On Tue, Jun 26, 2018, 11:43 PM Jacco van Dorp wrote:
>>
>> 2018-06-26 17:34 GMT+02:00 Franklin? Lee :
>> > Caller detects: The caller checks length before calling the dunder. If
>> > there
>> > is n
2018-06-26 17:34 GMT+02:00 Franklin? Lee :
> Caller detects: The caller checks length before calling the dunder. If there
> is no dunder, it doesn't check. Are there real-world cases where length is
> not defined on an iterable collection?
Generators dont have a __len__ method. And they might have
For changes that break this much previous code, you need a really,
really, really good reason.
"Even though it's kind of weird, I find the separation between
addition and concatenation useful."
does not qualify.
___
Python-ideas mailing list
Python-idea
To clarify some more, you'd then have to use the decorator like:
@type_check_on_traceback
def three(arg: str) -> str:
return "{}({}) ".format(arg, len(arg))
on every function where you want this behaviour. Note that this will
also emit warnings on tracebacks of exceptions that are later
silen
2018-06-20 11:43 GMT+02:00 Daniel Sánchez Fábregas
:
>
> El 14/06/18 a las 14:37, Steven D'Aprano escribió:
>> On Thu, Jun 14, 2018 at 01:03:37PM +0200, Daniel Sánchez Fábregas wrote:
>>> My idea consist in:
>>> Adding a method to perform type checking in traceback objects
>>> When printing stack t
from a lurker's perspective, why not just implement str.compile() as
new method, and methods where it's relevant support it's result as
argument ? That's a small change in additions, and the other methods
in the normal case just do the same as now. It's also pretty clear
what things like "whatever"
2018-06-11 10:00 GMT+02:00 Ronald Oussoren :
>> [me suggestion PiMultiple class]
>
> What is the real world advantage of such a class? So far I’ve only seen
> examples where the current behavior is said to be confusing for students. In
> most cases where I have used math.sin the angle wasn’t a
> Remember, because π is irrational, we cannot actually call sin or cos on
> any rational multiple of π. We can only operate on multiples of pi,
> which is *close to* but not the same as π. That's why it is okay that
> tan(pi/2) returns a huge number instead of infinity or NAN. That's
> because the
I'd use a class or simple import a 5-line module if I wanted a
namespace like that. Seems like clearner solutions to me.
If you feel that your module namespace has to much content for a
simple namespace, putting it in a seperate module should be the way to
go anyway.
__
Given that an exhaust method for generators didn't make it, I dont
think a keyword has more chance. For reference, that exhaust method
would have looked like:
(print (x) for x in range(50)).exhaust()
and be defined as:
def exhaust(self):
for _ in self:
pass
Also, there was some more
2018-06-08 15:19 GMT+02:00 Hugh Fisher :
>> Julia provides a full set of trigonometric functions in both radians and
>> degrees:
>>
>> https://docs.julialang.org/en/release-0.4/manual/mathematical-operations/#trigonometric-and-hyperbolic-functions
>>
>> They use sind, cosd, tand etc for the varian
Or when students get stuff e-17 out of a function, you teach them what
floating point numbers are and what gotcha's they can expect. The
simple version is "value is stored as a float, and a float gets
rounding errors below e-16", or for the more inquisitive minds you
give them nice places like
http
2018-06-06 14:51 GMT+02:00 Chris Angelico :
> On Wed, Jun 6, 2018 at 7:51 PM, Jacco van Dorp wrote:
>> For the startup time, you could keep it around as builtin but save the
>> import time until someone actually uses it.
>
> That would mean creating a system of lazy
For the startup time, you could keep it around as builtin but save the
import time until someone actually uses it.
While I agree sqrt should be a builtin as well, I think there's a good
argument to be made for Path to. I just switched to it the past month,
and im liking it a lot over constructs li
i'd also be pretty simple to implement
Just list:
minute = timedelta(minutes=1)
hour = timedelta(hours=1)
etc...
and you could import and use them like that. Or if you really want to
write 5*m, the just from datetime import minute as m
___
Python-id
2018-06-05 10:08 GMT+02:00 Pål Grønås Drange :
>> You can't import literals. They're syntax, not just bound names.
>
> I'm way out of my comfort zone now, but the parser could for
> `123.45_f`
> give
> `__literal_f__(123.45)`
> and then that function should be imported.
>
> I'm sure this idea has m
I'd say seconds(), minutes() etc functions in the datetime module
might be good. Same for better docstrings.
I dont really think it's worth adding literals though.
@Pål
You can't import literals. They're syntax, not just bound names.
(Unless we're counting future imports, but those aren't real im
Bright idea the moment after sending that mail:
You could remove the globals() hack if you make it a class decorator instead.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: htt
2018-05-28 11:07 GMT+02:00 Michael Lohmann :
> But maybe it is just me who thinks that you should make it as obvious as
> possible what a class itself really can get as an input and what is done just
> to get the multiple inheritance to work... So I think if no one else agrees
> with me, we don’
2018-05-28 9:44 GMT+02:00 Michael Lohmann :
>
>> I'd say NOT wanting to call an __init__ method of a superclass is a
>> rather uncommon occurence. It's generally a huge error. So I think
>> it's worth not accomodating that.
>
> I will give you an example then where I am absolutely fine with calling
I'd say NOT wanting to call an __init__ method of a superclass is a
rather uncommon occurence. It's generally a huge error. So I think
it's worth not accomodating that.
2018-05-28 9:27 GMT+02:00 Michael Lohmann :
>
>>>class Magic:
>>>magic_number = 42
>>>def __init__(self):
>>>
2018-05-26 11:24 GMT+02:00 Antoine Rozo :
> Dismiss my message, I have read `if "art_wt" not in article`. But in the
> same way, you could have a function to reset a value in your dict if the
> current value evaluates to False.
That won't work, since at other places, I do the same with bools and
s
2018-05-26 11:00 GMT+02:00 Kirill Balunov :
> The main point is to collect more information, since the idea of assignment
> expression will have a huge impact in all aspects of Python programming: how
> you structure your programm, how you write code, how you read code, how you
> parse code... Beca
2018-05-25 14:57 GMT+02:00 Elazar :
> The title is misleading - this has nothing to do with the conditional
> operator, except small syntactic similarity.
On second look, yeah, you're right.
___
Python-ideas mailing list
Python-ideas@python.org
https://m
2018-05-25 14:26 GMT+02:00 Kirill Balunov :
> If it is an expression, what should `do_something if cond` return on
> failure? If you don't care you can already use `cond and do_something`.
Duh, forgot to mention.
I wouldn't have it return anything. Ternary returns something because
you have two op
I would like to carefully suggest a half form of the ternary expression.
Currently, you can write code like:
>>> if cond:
>>>do_something
However, especially if the condition and action are both really
simple, taking two lines feels like a bit of a waste. So I sometimes
write:
>>> if cond:
While I understand the attraction, I think the clarity cost might be to high.
If it's a pain to explain it to an IDE, it's an even bigger pain to
explain it to people new to the language.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail
I think we're approaching this from the wrong direction.
My point is, expression assignments dont have the complex case as
purpose - most coders wont try to maximize line information density.
If you're doing magic, you might as well spell it out over multiple
lines, because neither := nor given wi
A while ago, we had this gem:
2018-04-06 8:19 GMT+02:00 Serhiy Storchaka :
> Using currently supported syntax:
>
> smooth_signal = [average for average in [0] for x in signal for average
> in [(1-decay)*average + decay*x]]
Go ahead and understand that line in 1 go. It's currently legal synta
>[Rhodri]
> I respectfully disagree with your opinion (i.e. you're wrong :-)
>
> Consider:
>
> while (cmd := get_command()).token != CMD_QUIT:
> cmd.do_something()
>
> vs:
>
> while cmd.token != CMD_QUIT given cmd = get_command():
> cmd.do_something()
>
Actually, the first version is m
2018-05-11 11:56 GMT+02:00 João Santos :
> Optimizing syntax for space makes sense for "mathematical" notation since
> it's commonly written by hand, but putting space above readability in a
> programming language design feels like a skewmorphism.
You are assuming "given" to improve readability, w
I dont really like "given".
If we compare:
if m given m = re.match(stuff):
to
if m := re.match(stuff)
then I count 4+(name_length) more tokens and 2 more spaces. Since I
believe := is perfectly clear, I don't see the reason for a far more
verbose syntax.
That all said, I would still prefer:
>[Tim]
> Since this is all about scope, while I'm not 100% sure of what Guido
> meant, I assumed he was saying "p can only have one scope in the
> synthetic function: local or non-local, not both, and local is what I
> propose". For example, let's flesh out his example a bit more:
>
> p = 42
My apologies for something unclear in my previous mail - the second
block I quoted (the one without a name) originated from Guido, not
from Tim.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Co
> [Tim]
> {About binding the for loop variable}
Yeah, that binding is the one I attempted to refer to. So I did
understand you after all.
> We should probably define what happens when you write [p := p for p in
> range(10)]. I propose that this overwrites the loop control variable rather
> than c
> [Tim]
> (inside a synthetic function created to
> implement a listcomp/genexp, names bound by "=" are local; names bound
> by ":=" are nonlocal; names bound by both are "who cares?"-
> compiler-time error would be fine by me, or the first person to show a
> real use case wins).
Wait, you can't u
2018-05-07 21:56 GMT+02:00 Neil Girdhar :
> Regular expressions are not just "an order of magnitude better"—they're
> asymptotically faster. See
> https://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm
> for a non-regular-expression algorithm.
Hence my
>> [Jacco wrote, capita
For what it's worth, i'm totally +1 on inline uses of global and nonlocal.
As a related improvement, i'd also like it if "global x = 5" would be
a legal statement. As a noob learning python, I was suprised to find
out I couldn't and had to split it on two lines.(aside from a 9-hour
course of C and
Would this be valid?
# Pattern matching with guards
x = 'three'
number = match x:
1 => "one"
y if y is str => f'The string is {y}'
z if z is int => f'the int is {z}'
_ => "anything"
print(number) # The string is three
If so, why are y and z both valid here ? Is the match variab
> # Pattern matching with guards
> x = 'three'
>
> number = match x:
>1 => "one"
>y if y is str => f'The string is {y}'
>_ => "anything"
>
> print(number) # The string is three
I think you meant to use isinstance(y, str) ?
This looks like an incomplete ternary as well, missing the els
I kind of strangely like this, but it does something completely
different from parens or []. Those do have something in common -
func(param) and indexable[index] both result in some value obtained in
some way by combining the two names - either it's the result of func
when called with param, or it
> I think this method is easy to miss, since people look at the docs for bytes
> (e.g. using dir(bytes)). It might be worthwhile to either add a
> `bytes.to_int(...)` method (better, IMHO), or to point to int.from_bytes on
> the relevant part of the docs.
>
> Elazar
A note in the docs about int.fr
2018-05-01 14:54 GMT+02:00 Greg Ewing :
> Rhodri James wrote:
>>
>> I'd be interested to know if there is a readability difference between
>> really_long_descriptive_identifier_name and
>> ReallyLongDescriptiveIdentifierNames.
>
>
> As one data point on that, jerking my eyes quickly across
> that l
I must say my gut agrees that
really_long_identifier_names_with_a_full_description don't look
readable to me. Perhaps it's my exposure to (py)Qt, but I really like
my classes like ThisName and my methods like thisOne. I also tend to
keep them to three words max (real code from yesterday:
getActiveO
2018-04-26 15:26 GMT+02:00 Nick Coghlan :
> On 26 April 2018 at 19:37, Jacco van Dorp wrote:
>> I'm kind of curious why everyone here seems to want to use IntFlags
>> and other mixins. The docs themselves say that their use should be
>> minimized, and tbh I agree with th
or build it yourself...
def str_count(string, sub):
c = 0
for c in range(len(string)-len(sub)):
if string[c:].startswith(sub):
c += 1
return c
(probably some optimizations possible...)
Or in one line with a generator expression:
def str_count(string, sub):
return sum(string[c:]
I'm kind of curious why everyone here seems to want to use IntFlags
and other mixins. The docs themselves say that their use should be
minimized, and tbh I agree with them. Backwards compatiblity can be
maintained by allowing the old value and internally converting it to
the enum. Combinability is
PM, Guido van Rossum wrote:
>
> On Wed, Apr 25, 2018, 02:13 Jacco van Dorp wrote:
>>
>> ... Which is where the auto-completion comes in. ...
>
>
> Designing the language with auto-complete in mind feels wrong to me. It
> assumes a very sophisticated IDE and may lead
2018-04-25 10:30 GMT+02:00 Chris Angelico :
> On Wed, Apr 25, 2018 at 6:06 PM, Jacco van Dorp wrote:
>>> First, though, can you enumerate (pun intended) the problems with
>>> magic strings? You list "no magic strings" as a benefit, as if it's
>&
> First, though, can you enumerate (pun intended) the problems with
> magic strings? You list "no magic strings" as a benefit, as if it's
> self-evident; I'm not sure that it is.
>
> ChrisA
One of my main reasons would be the type-checking from tools like
Pycharm, which is the one I use. If I don'
I
2018-04-24 15:58 GMT+02:00 Nick Coghlan :
> On 24 April 2018 at 22:52, Jacco van Dorp wrote:
>> Wouldn't it be cleaner to use enums by default instead of those magic
>> strings ? for example, for warnings filter actions, (section 29.5.2),
>> quite near the top of t
A bit ago I was reading some of the python docs (
https://docs.python.org/3.6/library/warnings.html ), the warning
module, and I noticed a table of magic strings.
I can think of a few other places where magic strings are used - for
example, string encoding/decoding locales and strictness, and prob
> I'm saying, don't even try to distinguish between the forms with or
> without parens. If we add parens:
>
> with (expr as name):
>
> it may or may not be allowed some time in the future (since it isn't
> allowed now, but there are many requests for it) but if it is allowed,
> it will still me
Before, I briefly mentioned the idea if this could be unified with
except/with's "as". To the casual observer, they're really similar.
However, their semantics would be totally different, and people don't
seem to like a unification attempt.
A huge argument against "as" would be to prevent confusi
2018-04-12 15:02 GMT+02:00 Nick Coghlan :
> On 12 April 2018 at 22:22, Jacco van Dorp wrote:
>> I've looked through PEP 343, contextlib docs (
>> https://docs.python.org/3/library/contextlib.html ), and I couldn't
>> find a single case where "with (y := f(x))&
2018-04-12 13:28 GMT+02:00 Kirill Balunov :
>
>
> 2018-04-12 12:48 GMT+03:00 Jacco van Dorp :
>>
>> Wouldn't these local name bindings make the current "as" clause of
>> "with f(x) as y" completely obsolete ?
>>
>> It's pro
Wouldn't these local name bindings make the current "as" clause of
"with f(x) as y" completely obsolete ?
It's probably good to know my background, and my background is that I
know completely nothing of the implementation, im only junior software
engineer, and python was my first programming exper
I must say I can't really see the point either. If you say like:
> {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}}
Do you basically mean:
c = {'a': 1, **{'b': 2}}
a = c.pop("a")
b = c.pop("b") # ?
That's the only thing I could think of.
I think most of these problems could be solved with pop a
> With the increased emphasis on iterators and generators in Python 3.x,
> the lack of a simple expression level equivalent to "for item in
> iterable: pass" is occasionally irritating, especially when
> demonstrating behaviour at the interactive prompt.
I've sometimes thought that exhaust(iterato
Currently, you cannot use isinstance checks on threading locks, because
they're created by a factory function instead of being actual classes.
Now that we've got __subclasshook__ and __instancecheck__, is there
still a reason other than "history" that we can't use isinstance here ? There
could ex
87 matches
Mail list logo
