Joshua Landau added the comment:
Sorry, I'd stumbled on my old comment on the closed issue and completely forgot
about the *last* time I did the same thing.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Joshua Landau:
This is effectively a continuation of https://bugs.python.org/issue9712.
The line in Lib/tokenize.py
Name = r'\w+'
must be changed to a regular expression that accepts Other_ID_Start at the
start and Other_ID_Continue elsewhere. Hence tokenize does
Changes by Joshua Landau <joshua.landau...@gmail.com>:
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Joshua Landau added the comment:
This should also be applied to regex.search's docstring.
https://docs.python.org/3.5/library/re.html#re.regex.search
--
resolution: fixed -
status: closed - open
___
Python tracker rep...@bugs.python.org
http
New submission from Joshua Landau:
This is valid:
℘· = 1
print(℘·)
# 1
But this gives an error token:
from io import BytesIO
from tokenize import tokenize
stream = BytesIO(℘·.encode(utf-8))
print(*tokenize(stream.read), sep=\n)
# TokenInfo(type=56 (ENCODING
Joshua Landau added the comment:
There is a change as part of this to make dict building more like list and set
building, which both have this behaviour.
The same changes have likely occurred before whenever BUILD_LIST and BUILD_SET
were introduced, and this behaviour seems particularly
Joshua Landau added the comment:
This doesn't seem to be a complete fix; the regex used does not include
Other_ID_Start or Other_ID_Continue from
https://docs.python.org/3.5/reference/lexical_analysis.html#identifiers
Hence tokenize does not accept '℘·'.
Credit to modchan from http
Joshua Landau added the comment:
I don't know the etiquette rules for the issue tracker, but I'd really
appreciate having something to debug -- it's working for me, you see.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Joshua Landau added the comment:
Special-cased `(*i for i in x)` to use YIELD_FROM instead of looping. Speed
improved, albeit still only half as fast as chain.from_iterable.
Fixed error message check in test_syntax and removed semicolons.
--
Added file: http://bugs.python.org
Joshua Landau added the comment:
Quick-fix for Guido's bug attached. I'm not familiar with this part of the
code, yet, so take this tentatively. I just changed
while (containers 1) {
to
while (containers) {
---
@Guido
My comments were assuming `f(**x for x in y)` meant `f({**x
Joshua Landau added the comment:
Update for the error messages fix.
I've put aside the idea of unifying things for now because there are a couple
of interdependencies I wasn't expecting and I absolutely don't want the
fast-path for f(x) to get slower.
--
Added file: http
Joshua Landau added the comment:
If we're supporting
f(**x for x in y)
surely we should also support
f(x: y for x, y in z)
I personally don't like this idea.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
New submission from Joshua Landau:
It is claimed that all expressions are evaluated left-to-right, including in
functions¹. However,
f(*a(), b=b())
will evaluate b() before a().
¹ https://docs.python.org/3/reference/expressions.html#evaluation-order
--
components: Interpreter
Joshua Landau added the comment:
Amazing, thanks.
I also just uncovered http://bugs.python.org/issue23316; we'll need to support
a patch for that. In fact, bad evaluation order is why I haven't yet gotten
down my unification strategy. I wouldn't worry about extra opcodes when using
*args
Joshua Landau added the comment:
I've looked at BUILD_MAP(n). It seems to work and has speed improvements but:
- I was wrong about the 16-bit int thing. It turns out CPython is happily
treating them as 32 bit as long as they are prefixed by an EXTENDED_ARG bytecode
https://docs.python.org
Joshua Landau added the comment:
Why would that simplify things?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list
Joshua Landau added the comment:
I phrased that badly. Whilst I can see minor simplifications to
BUILD_MAP_UNPACK, the only way to add more information to CALL_FUNCTION_XXX
would be through EXTENDED_ARG. This seems like it would outweigh any benefits,
and the tiny duplication of error
Joshua Landau added the comment:
We wouldn't actually need to raise it from somewhere else; the line numbering
and frame are already correct. The only difficulty is that the traceback
currently says
# func(a=1, **{'a': 1})
TypeError: func() got multiple values for keyword argument
Joshua Landau added the comment:
The function object that's on the stack.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python
Joshua Landau added the comment:
Just before any arguments to the function.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python
Joshua Landau added the comment:
No, that happens in CALL_FUNCTION_KW:
import dis
dis.dis(f(x=1, **{'x': 1}))
1 0 LOAD_NAME0 (f)
3 LOAD_CONST 0 ('x')
6 LOAD_CONST 1 (1)
9 LOAD_CONST
Joshua Landau added the comment:
I imagine it like (in the map unpacking code)
func_offset = (oparg 8) 0xFF;
num_maps = oparg 0xFF;
// later
if (func_offset) {
// do checks
if (repeated_argument) {
raise_error_from_function(PEEK(func_offset
Joshua Landau added the comment:
The stack will have the function, then any number of positional arguments, then
optionally an *args, then any number (= 2) of maps to unpack. To get to the
function, you need to know the sum count of all
Joshua Landau added the comment:
I think I've fixed the memory leaks (plural).
There were also a host of other problems with the _UNPACK opcodes in ceval.
Here are the things I remember fixing, although I think I did slightly more:
- Not throwing an error when PyDict_New or PyDict_Update
Joshua Landau added the comment:
The _UNPACK opcodes are new in this changelist.
Yup, but they're used in the other unpacking syntax too:
(*(1, 2, 3), *(4, 5, 6))
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
Joshua Landau added the comment:
According to the standard, int can be only 16 bits long so that only leaves
255/255. However, if the offset is on top of the dictionary count, this is
easily enough to clear the limits for the maximum function size (worst case is
a merge of 255 dicts
Joshua Landau added the comment:
Functions are already limited to 255 arguments, so I don't think so.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
Joshua Landau added the comment:
We wouldn't want to replace STORE_MAP since that's used in dictionary
comprehensions, but replacing BUILD_MAP with BUILD_MAP(n) sounds like a great
idea.
--
___
Python tracker rep...@bugs.python.org
http
Joshua Landau added the comment:
Good catch.
CALL_FUNCTION seems to split its opcode into two to give it a
positional-keyword pair so this seems fine. I'd hope we can do the same thing;
personally I would do:
BUILD_MAP_UNPACK(
position_of_function_in_stack_or_0 8
Joshua Landau added the comment:
Some of the tests seemed to be failing simply because they were incorrect. This
fixes that.
--
Added file: http://bugs.python.org/file37806/starunpack12.diff
___
Python tracker rep...@bugs.python.org
http
Joshua Landau added the comment:
The problem seems to be that with the removal of
-else if (TYPE(ch) == STAR) {
-vararg = ast_for_expr(c, CHILD(n, i+1));
-if (!vararg)
-return NULL;
-i++;
-}
-else if (TYPE(ch
Joshua Landau added the comment:
This was a rather minor fix; I basically moved from STORE_SUBSCR to STORE_MAP
and fixed a BUILD_MAP opcode.
--
Added file: http://bugs.python.org/file37795/starunpack7.diff
___
Python tracker rep...@bugs.python.org
Joshua Landau added the comment:
Aye, I'd done so (see starunpack7.diff). It was the fuss to reapply it ontop of
your newer diff and making sure I'd read at least *some* of the devguide before
barging on.
Anyhow, here's another small fix to deal with the [*[0] for i in [0]] problem.
I'm
Joshua Landau added the comment:
I'm getting
f(x=5, **{'x': 1}, **{'x': 3}, y=2)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: f() got multiple values for keyword argument 'x'
Which, as I understand, is the correct result. I'm using starunpack8
Joshua Landau added the comment:
The problem with using STORE_MAP is you create a new dict for each keyword
argument in that situation.
You don't; if you look at the disassembly for producing a built-in dict
(dis.dis('{1:2, 2:3, 3:4}')) you'll see they use STORE_MAP too. STORE_MAP
seems
Joshua Landau added the comment:
I think I've got it working; I'm just working out how to make a patch and
adding a test or two. I think I'll also need to sign the contributor agreement.
While I'm at it, here are a few other deviations from the PEP:
- {*()} and {**{}} aren't supported
Joshua Landau added the comment:
2 here as well:
15 LOAD_CONST 2 ('w')
18 LOAD_CONST 3 (1)
21 BUILD_MAP1
24 LOAD_CONST 4 (2)
27 LOAD_CONST 5 ('x')
30 STORE_MAP
31 BUILD_MAP1
34 LOAD_CONST
On 20 January 2015 at 04:21, Dan Stromberg drsali...@gmail.com wrote:
On Mon, Jan 19, 2015 at 6:46 PM, Mark Lawrence breamore...@yahoo.co.uk
wrote:
I don't know if you've seen this http://kmike.ru/python-data-structures/ but
maybe of interest.
I've seen it. It's a nice page.
I attempted
Joshua Landau added the comment:
I take it back; that just causes
f(**{}, c=2)
XXX lineno: 1, opcode: 105
Traceback (most recent call last):
File stdin, line 1, in module
SystemError: unknown opcode
--
___
Python tracker rep
Joshua Landau added the comment:
This causes a segmentation fault if any keyword arguments come after a
**-unpack. Minimal demo:
f(**x, x=x)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
Joshua Landau added the comment:
Just change
if (!PyUnicode_Compare(tmp, key)) {
when iterating over prior keyword arguments to
if (tmp !PyUnicode_Compare(tmp, key)) {
since tmp (the argument's name) can now be NULL.
--
___
Python
To: python-list
On 7 December 2014 at 14:31, Albert-Jan Roskam
fo...@yahoo.com.dmarc.invalid wrote:
On Sun, Dec 7, 2014 11:06 AM CET Stefan Behnel wrote:
I think this is trying to position PyPy more in the same corner as other
JIT compilers for CPython, as opposed to keeping it a completely
On 7 December 2014 at 14:31, Albert-Jan Roskam
fo...@yahoo.com.dmarc.invalid wrote:
On Sun, Dec 7, 2014 11:06 AM CET Stefan Behnel wrote:
I think this is trying to position PyPy more in the same corner as other
JIT compilers for CPython, as opposed to keeping it a completely separate
thing which
On 3 December 2014 at 04:32, Skybuck Flying skybuck2...@hotmail.com wrote:
I am still new at python and definetly don't feel comfortable with the
object feature, though I did use it for these variables which are actually
objects.
If you are being serious, please take into consideration that
On 3 December 2014 at 08:29, Michael Kreim mich...@perfect-kreim.de wrote:
What are you using to wrap C++ classes for Python?
Can you recommend swig? Should I give it another try?
Did I misunderstood ctypes?
The PyPy guys would love it if you used CFFI. Cython is also a
wonderful approach.
On 29 October 2014 03:22, Rustom Mody rustompm...@gmail.com wrote:
Yesterday I was trying to introduce python to some senior computer scientists.
Tried showing a comprehension-based dir-walker vs a for-loop based one:
def dw(p):
if isfile(p):
return [p]
else:
return [p]
On 28 October 2014 00:36, Denis McMahon denismfmcma...@gmail.com wrote:
d = [[list(range(1,13))[i*3+j] for j in range(3)] for i in range(4)]
A quick note. Ranges (even 2.7's xrange) are all indexable. The cast
to a list isn't needed.
--
https://mail.python.org/mailman/listinfo/python-list
On 27 October 2014 00:12, Dan Stromberg drsali...@gmail.com wrote:
Are the following two expressions the same?
x is y
Id(x) == id(y)
Much of the time, but not all the time. The obvious exception is if
id is redefined, but that one's kind of boring. The real thing to
watch out for is if the
On 26 October 2014 01:03, Ben Finney ben+pyt...@benfinney.id.au wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
I suspect that Guido and the core developers disagree with you, since
they had the opportunity to fix that in Python 3 and didn't.
That doesn't follow; there
On 27 October 2014 02:28, Ben Finney ben+pyt...@benfinney.id.au wrote:
Joshua Landau jos...@landau.ws writes:
Guido van Rossum answered Jul 28 '11 at 21:20,
http://stackoverflow.com/questions/3174392/is-it-pythonic-to-use-bools-as-ints
False==0 and True==1, and there's nothing wrong
On 7 October 2014 17:15, jonathan.slend...@gmail.com wrote:
Probably I'm turning the use of regular expressions upside down with this
question. I don't want to write a regex that matches prefixes of other
strings, I know how to do that. I want to generate a regex -- given another
regex --,
Joshua Landau added the comment:
That sounds OK to me. It's a bit of a non-issue once you know about it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22451
New submission from Joshua Landau:
All code referred to is from bltinmodule.c, Python 2.7.8:
https://github.com/python/cpython/blob/2.7/Python/bltinmodule.c
filter implements and optimization for PyBool_Type, making it equivalent to
PyNone:
# Line 303
if (func == (PyObject
Joshua Landau added the comment:
It's solely a speed thing. I think it was an oversight that the optimisation
was only applied to lists. I didn't expect the optimisation to break when
applied to tuples.
--
___
Python tracker rep...@bugs.python.org
On 8 September 2014 12:54, David H. Lipman DLipman~nospam~@verizon.net wrote:
From: Ned Batchelder n...@nedbatchelder.com
On 9/7/14 5:41 PM, Tony the Tiger wrote:
Now, kindly get the fuck outta here, you fucking retard!
That was unnecessary, ineffective, and totally outside the bounds of
On 3 September 2014 15:48, c...@isbd.net wrote:
Peter Otten __pete...@web.de wrote:
[ord(c) for c in This is a string]
[84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103]
There are other ways, but you have to describe the use case and your Python
version for us to
On 23 August 2014 23:53, Chris Angelico ros...@gmail.com wrote:
On Sun, Aug 24, 2014 at 8:47 AM, Joshua Landau jos...@landau.ws wrote:
On 23 August 2014 23:31, Chris Angelico ros...@gmail.com wrote:
I'd say never is too strong (there are times when it's right to put
an import inside a function
On 23 August 2014 22:55, Rustom Mody rustompm...@gmail.com wrote:
On Sunday, August 24, 2014 2:27:56 AM UTC+5:30, Joshua Landau wrote:
Ay, so is any editor with an API. I use Sublime mostly because it's
pretty, fast and has a Python-based API. The only actual feature it
has that some others
On 24 August 2014 20:19, Ian Kelly ian.g.ke...@gmail.com wrote:
On Sun, Aug 24, 2014 at 1:17 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Sun, Aug 24, 2014 at 1:12 PM, Joshua Landau jos...@landau.ws wrote:
Is math not already imported by start-up?
Why would it be?
It's easy to check
On 24 August 2014 20:25, Joshua Landau jos...@landau.ws wrote:
On 24 August 2014 20:19, Ian Kelly ian.g.ke...@gmail.com wrote:
On Sun, Aug 24, 2014 at 1:17 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Sun, Aug 24, 2014 at 1:12 PM, Joshua Landau jos...@landau.ws wrote:
Is math not already
On 24 August 2014 20:40, Ian Kelly ian.g.ke...@gmail.com wrote:
That's the same check I posted, just using the in operator instead of a
straight lookup and raising an error.
I think I need to take a break from the internet. This is the second
time in as many threads that I've responded with
(Since this is already an editor war...)
On 23 August 2014 10:41, Christian Gollwitzer aurio...@gmx.de wrote:
Sometimes I impress my colleagues with what they call magic, i.e. creating
special repeated lists of numbers by a few keystrokes in gvim, and that has
triggered the request from them
On 23 August 2014 17:17, Christian Gollwitzer aurio...@gmx.de wrote:
Am 23.08.14 16:19, schrieb Joshua Landau:
On 23 August 2014 10:41, Christian Gollwitzer aurio...@gmx.de wrote:
Sometimes I impress my colleagues with what they call magic, i.e.
creating
special repeated lists of numbers
On 23 August 2014 18:47, Seymore4Head Seymore4Head@hotmail.invalid wrote:
Anyone care to suggest what method to use to fix the decimal format?
It sounds like you want a primer on floating point. The documentation
of the decimal module is actually a good read, although I don't doubt
there are
On 23 August 2014 22:13, Seymore4Head Seymore4Head@hotmail.invalid wrote:
def make_it_money(number):
import math
return '
+ str(format(math.floor(number * 100) / 100, ',.2f'))
So for one import math should never go inside a function; you should
hoist it to the top of the file with all
On 23 August 2014 23:31, Chris Angelico ros...@gmail.com wrote:
On Sun, Aug 24, 2014 at 7:47 AM, Joshua Landau jos...@landau.ws wrote:
So for one import math should never go inside a function; you should
hoist it to the top of the file with all the other imports.
I'd say never is too strong
On 15 July 2014 23:40, Abhiram R abhi.darkn...@gmail.com wrote:
On Wed, Jul 16, 2014 at 4:00 AM, Kevin Walzer k...@codebykevin.com wrote:
...but Unix/newsgroup ettiquette says that it's gauche to [top post],
because it presents an unacceptable cognitive burden to the user trying to
catch the
On 12 June 2014 03:08, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
We know *much more* about generating energy from E = mc^2 than we know
about optimally flipping bits: our nuclear reactions convert something of
the order of 0.1% of their fuel to energy, that is, to get a
On 8 June 2014 08:12, Marko Rauhamaa ma...@pacujo.net wrote:
Does anyone have an example motivating a return from finally? It seems
to me it would always be a bad idea as it silently clears all unexpected
exceptions.
In a general sense:
try:
something_that_can_break()
On 6 June 2014 18:39, Roy Smith r...@panix.com wrote:
The only way I can think of to bypass a finally block would be to call
os._exit(), or send yourself a kill signal.
If you're willing to use implementation details...
---
# BreakN.py
import sys
# Turn tracing on if it is off
if
On 4 June 2014 15:50, Michael Torrie torr...@gmail.com wrote:
On 06/04/2014 12:50 AM, wxjmfa...@gmail.com wrote:
[Things]
[Reply to things]
Please. Just don't.
--
https://mail.python.org/mailman/listinfo/python-list
Joshua Landau added the comment:
Here's a minimal example of the difference:
1e
# ... etc ...
# SyntaxError: invalid token
1t
# ... etc ...
# SyntaxError: invalid syntax
--
___
Python tracker rep...@bugs.python.org
http
New submission from Joshua Landau:
By the docs,
Except at the beginning of a logical line or in
string literals, the whitespace characters space,
tab and formfeed can be used interchangeably to
separate tokens. Whitespace is needed between two
tokens only
New submission from Joshua Landau:
The documentation for re.search does not state that it returns the first match.
This should be added, or a clarification added if this is
implementation-defined.
https://docs.python.org/3/library/re.html#re.search
---
See also
http://stackoverflow.com
New submission from Joshua Landau:
There are tabs in the source:
http://hg.python.org/cpython/file/5c8d71516235/Include/listobject.h#l49
I don't really know, but this seems like a release blocker to me ;).
--
messages: 219183
nosy: Joshua.Landau
priority: normal
severity: normal
New submission from Joshua Landau:
In the docs for 2.x about the formatting syntax:
https://docs.python.org/2/library/string.html#format-string-syntax
it says
Two conversion flags are currently supported: '!s' which calls str() on
the value, and '!r' which calls repr
On 9 May 2014 22:06, Chris Angelico ros...@gmail.com wrote:
On Sat, May 10, 2014 at 6:45 AM, jun...@gmail.com wrote:
2 - Jit compiler for using from a web server. I mean, one has a web server
running under Apache in a hosting service like Hostgator, Daddy Host or
another inexpensive
Is there any reference for this strange behaviour on Python 2:
set() dict().viewkeys()
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: can only compare to a set
dict().viewkeys() set()
False
?
--
On 20 April 2014 20:27, Ivan Ivanivich ivriabt...@gmail.com wrote:
thanks, i found the bag
G'day.
This [https://xkcd.com/979/] applies to threads ending in nvm, solved
it too. I know the problem in your case isn't likely to be widely
useful, but there are other benefits of pointing out what
On 15 April 2014 06:03, Marko Rauhamaa ma...@pacujo.net wrote:
Terry Reedy tjre...@udel.edu:
Any decent system should have 3.4 available now.
Really, now? Which system is that?
Arch is on 3.4 *default*.
$ python
Python 3.4.0 (default, Mar 17 2014, 23:20:09)
[...]
--
On 15 April 2014 23:18, Ned Batchelder n...@nedbatchelder.com wrote:
On 4/15/14 5:34 PM, Joshua Landau wrote:
Arch is on 3.4 *default*.
$ python
Python 3.4.0 (default, Mar 17 2014, 23:20:09)
[...]
Yeah, that's the wrong way to do it, and they shouldn't have done
On 16 April 2014 01:42, Devin Jeanpierre jeanpierr...@gmail.com wrote:
Yes. Software included in Arch, and programs installed via distutils,
will both work correctly under Arch. [...]
I don't like how Arch
created a situation where it was impossible to support Arch and Debian
at the same
On 11 April 2014 02:29, Wesley nisp...@gmail.com wrote:
Does python has any good obfuscate?
Most other people on the list will point out why such a thing is
mostly pointless and you don't really need it.
However, if this really is your major blocker to using Python, I
suggest compiling with
On 11 April 2014 10:17, Sturla Molden sturla.mol...@gmail.com wrote:
Joshua Landau jos...@landau.ws wrote:
However, if this really is your major blocker to using Python, I
suggest compiling with Cython.
Cython restains all the code as text, e.g. to readable generate exceptions.
Users can
On 18 March 2014 01:01, Daniel Stutzbach stutzb...@google.com wrote:
I would love to have include macro-benchmarks. I keep waiting for the PyPy
benchmark suite to get ported to Python 3...
*grins*
Delete a slice is fudged from its inclusion of multiplication, which
is far faster on blists.
On 17 March 2014 21:16, Daniel Stutzbach stutzb...@google.com wrote:
On Fri, Mar 14, 2014 at 6:13 PM, Joshua Landau jos...@landau.ws wrote:
Now, I understand there are downsides to blist. Particularly, I've
looked through the benchmarks and they seem untruthful.
I worked hard to make those
On 8 March 2014 20:37, Mark Lawrence breamore...@yahoo.co.uk wrote:
I've found this link useful http://kmike.ru/python-data-structures/
I also don't want all sorts of data structures added to the Python library.
I believe that there are advantages to leaving specialist data structures on
pypi
On 28 February 2014 14:43, Chris Angelico ros...@gmail.com wrote:
On Sat, Mar 1, 2014 at 1:41 AM, Joshua Landau jos...@landau.ws wrote:
Would it be better to add a check here, such that if this gets raised
to the top-level it includes a warning (Addition was inplace;
variable probably mutated
On 9 March 2014 18:13, Chris Angelico ros...@gmail.com wrote:
I think I see what you're saying here. But ignore top-level; this
should just be a part of the exception message, no matter what.
I don't think I was clear, but yes. That.
What you're saying is that this should notice that it's
On 27 February 2014 16:14, Chris Angelico ros...@gmail.com wrote:
On Fri, Feb 28, 2014 at 3:01 AM, Eric Jacoboni eric.jacob...@gmail.com
wrote:
a_tuple = (spam, [10, 30], eggs)
a_tuple[1] += [20]
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: 'tuple' object
On 15 February 2014 14:20, Ben Finney ben+pyt...@benfinney.id.au wrote:
Joshua Landau jos...@landau.ws writes:
Here, I give you a pdf. Hopefully this isn't anti
mailing-list-etiquette.
This forum is read in many different contexts, and attachments aren't
appropriate. You should simply put
On 5 February 2014 02:22, Dan Sommers d...@tombstonezero.net wrote:
On Tue, 04 Feb 2014 19:53:52 -0500, Roy Smith wrote:
In article ed1c2ddd-f704-4d58-a5a4-aef13de88...@googlegroups.com,
David Hutto dwightdhu...@gmail.com wrote:
Can anyone point out how using an int as a var is
On 30 January 2014 20:38, Chris Angelico ros...@gmail.com wrote:
Why is tuple unpacking limited to the last argument? Is it just for
the parallel with the function definition, where anything following it
is keyword-only?
You're not the first person to ask that:
On 31 January 2014 00:10, Rotwang sg...@hotmail.co.uk wrote:
On a vaguely-related note, does anyone know why iterable unpacking in calls
was removed in Python 3? I mean things like
def f(x, (y, z)):
return (x, y), z
I don't have a use case in mind, I was just wondering.
On 18 January 2014 20:51, Kevin K richyoke...@gmail.com wrote:
def foo(X, y, mylambda, N, D, epsilon):
...
for j in xrange(D):
aj = 0
cj = 0
for i in xrange(N):
aj += 2 * (X[i,j] ** 2)
cj += 2 * (X[i,j] * (y[i] -
On 17 January 2014 00:58, Sam lightai...@gmail.com wrote:
I would like to protect my python source code. It need not be foolproof as
long as it adds inconvenience to pirates.
Is it possible to protect python source code by compiling it to .pyc or .pyo?
Does .pyo offer better protection?
If
On 23 December 2013 20:53, Terry Reedy tjre...@udel.edu wrote:
On 12/23/2013 2:05 PM, wxjmfa...@gmail.com wrote:
Le lundi 23 décembre 2013 18:59:41 UTC+1, Wolfgang Keller a écrit :
[me]
I'll note that Python core developers do care about memory leaks.
And that's a really good thing.
On 11 November 2013 10:39, Chris Angelico ros...@gmail.com wrote:
On Mon, Nov 11, 2013 at 9:09 PM, lorenzo.ga...@gmail.com wrote:
Regarding the select statement, I think the most Pythonic approach is
using dictionaries rather than nested ifs.
Supposing we want to decode abbreviated day names
On 11 November 2013 22:21, Chris Angelico ros...@gmail.com wrote:
On Tue, Nov 12, 2013 at 7:50 AM, Joshua Landau jos...@landau.ws wrote:
The obvious way to me is a binary search:
Which makes an O(log n) search where I have an O(1) lookup. The
startup cost of denormalization doesn't scale, so
On 9 November 2013 13:08, John von Horn j@btinternet.com wrote:
I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am
enjoying working along to some youtube tutorials. I've done a little
programming in the past.
I've just got a few thoughts I'd like to share and ask
1 - 100 of 491 matches
Mail list logo
